[Slackbuilds-users] Call for Bug Fixes, Patches, etc

Andrzej Telszewski atelszewski at gmail.com
Sun Mar 13 18:23:50 UTC 2016


On 13/03/16 17:03, Erik Hanson wrote:
> On Sun, 13 Mar 2016 16:28:36 +0100
> Andrzej Telszewski <atelszewski at gmail.com> wrote:
>
>> On 13/03/16 16:23, Erik Hanson wrote:
>>> On Sun, 13 Mar 2016 15:34:25 +0100
>>> Johannes Schöpfer <johannes at schoepfer.info> wrote:
>>>
>>>> It would be helpful If someone could name a single reallife
>>>> example, where the chmod approach fails.
>>>
>>> It changes permissions of 700 to 755, which is something the 'find'
>>> lines don't do. The merits and circumstances behind this, or my
>>> choice of 700 as an example, do not matter and do not deserve
>>> debate. The fact is, it is undesired behavior.
>>>
>>>
>>
>> I'd say it shouldn't be a problem if we change all the permissions to
>> 755/644.
>
> We shouldn't assume to know why developers do what they do, and they
> may have some very specific reasons behind shipping some files with
> certain permissions.
>
>> It should be the job of _make install_ (or whatever else) to ensure
>> the correct permissions of sensitive files.
>>
>> Or am I wrong? ;)
>
> They may be build time requirements, we don't know. In any case, make
> install wouldn't be aware that those permissions had been changed,
> potentially resulting in a broken package.
>
>

You're correct. For the moment I thought what the heck, extracting 
tatball is going to modify the permissions, but...

With the default umask of 022, whatever the user permission bits are, 
they are going to survive extraction.

So something like 700 will definitely stay intact.

Although I have yet to come across software that actually depends on 
that behavior.

-- 
Best regards,
Andrzej Telszewski


More information about the SlackBuilds-users mailing list