bug#12130: "sudo make install" applies umask to new directories

[Stefano Lattarini]

On 08/10/2012 11:22 AM, Jason Eisner wrote:
> Dear Stefano - Thanks very much for your sympathetic reply on the directory
> permissions issue. As we haven't heard back further after a few days, I'd
> suggest going forward with plan 2.
> 
> You found that plan 2 was formerly proposed at
> <http://lists.gnu.org/archive/html/bug-automake/2003-05/msg00011.html>.  You
> suspected that it wasn't applied.  I believe that actually, it was applied,
> but then reverted because it broke someone's build.
>
> As I wrote in a followup to my original post:
> 
> Followup -- see this thread from 2004:
>>     http://www.digipedia.pl/usenet/thread/16496/9413/
>>
You're right; here's the same discussion archived on a more "official" site:

  <http://lists.gnu.org/archive/html/automake/2004-01/msg00013.html>

Thanks for correcting me and saving me from a potential mistake!

>> Looks like at one point, someone fixed this problem in the way I
>> suggested.  But then a user on that thread found directory permissions of
>> 755 too restrictive, which may have gotten the fix removed.
>>
>> One way to make everyone happy might be to ensure that a newly created
>> directory has permissions of *at least* 755.

>> (Although it's a bit peculiar to handle directories this way when
>> files are standardly 644 ...)
>
Exactly.  I believe we should either re-install the patch forcing the 755
permission on the intermediate directories, or enhance the install rules
to respect the user umask for the installation of regular files as well.
This is something to consider carefully though, and only to be changed (if
we decide to change it) in the next major automake version.  For now, we
should content ourselves with the documentation fix you proposed.

> In other words, perhaps the mode of the newly created directory (the XXX in
> mkdir -p -m XXX) needs to be be the bitwise "OR" of 755 and the current
> umask.
>
I disagree.  If we want to honour the user umask, we should do so fully;
half-hearted solutions (in one direction or another) will end up creating
confusion, and more problems than they solve.

> By erring on the side of permissiveness, this hack allows "make install" to
> succeed from any user account (as I hoped), while still preserving backward
> compatibility (for the guy who complained above in 2004 that he wanted it
> to work differently from HIS user account).
>
> This is one of those backward compatibility hacks that results in inelegant
> behavior.  I wish the 2004 guy had not relied on getting umask permissions
> for directories (he couldn't have relied on umask permissions for files,
> since those are standardly 644).  But it might be worth it if anyone is
> still relying on this behavior.
>
> If so, maybe the generated makefile should
> have a comment explaining that the "OR" with umask is only for backward
> compatibility with previous versions of automake.
> 
> cheers, jason
> 

Thanks,
  Stefano