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

[Stefano Lattarini]

On 08/03/2012 06:06 AM, Jason Eisner wrote:
> Hi automake folks,
>
Hi Jason, thanks for the report.

> There are many, many generic and specific installation guides that tell you
> to type something like
>       ./configure && make && sudo make install
> and I've been typing that for years.
> 
> Unfortunately, when installing OpenFST, I just discovered that the "sudo
> make install" part doesn't always work.  My umask is 0077, so any
> directories created with sudo (hence owned by root) are unreadable to
> ordinary users, including myself.
>
This is indeed annoying.

> Since following the documentation yields mysterious error messages and
> hard-to-fix errors[*] rather than the intended behavior, I believe that you
> should make ONE of the following changes:
> 
> 1. Fix the documentation: Correct the instructions to users to warn them
> that they should reset their umask before typing sudo make install.
>
This sounds like a good idea.  Care to attempt a patch?  Otherwise, I'll
get to write it myself eventually (not right now).

But then, reading further ...

> 2. Fix the behavior: Have "make install" set the permissions on
> directories, just as it already does on files.  For example, by using -m
> 755 as an option to mkdir, or otherwise overriding the umask.
>
... I see that a patch in this direction had already been proposed:
  <http://lists.gnu.org/archive/html/bug-automake/2003-05/msg00011.html>
but apparently never applied (the discussion died out).  Maybe we could
just resurrect it ...

Any opinion from the other autotoolers?

> 3. Don't fix the behavior outright, if you think for some reason that the
> user's umask should sometimes be respected on new directories. But then at
> least have "make install" issue a warning
>
That would likely be lost in the very verbose "make install" output,
sadly.

> or a y/n prompt when the current umask
>
Oh no, our rules are not going to get interactive by default; not even
conditionally ("if input/output is attached to a terminal, then print
a prompt and ...").  There lies madness.

>(or for that matter, restrictive permissions on existing directories)
> would result in installed resources that are not publicly readable.
> 
> My own preference would be for 2.
>
I'm undecided among 1 and 2, but leaning toward 2 by now.  I'll wait a
few days for some feedback by the other autotoolers before proceeding.

> I can't understand why make install
> treats directory permissions inconsistently with file permissions.
>
I'd guess hysterical raisins -- as is the case with many other warts and
rough edges in Automake.

> And I can't see why a single-user preference like a umask should be
> reflected in a global installation.
>
I agree it shouldn't.

> However, if there is some reason not to do 2., then I think you should do
> 1. or 3. to save at least some of the headaches.[*]
>

> This problem doesn't affect all packages -- only installations that create
> new directories.  But it has been raised repeatedly over the years.  To
> find numerous past reports, just do websearches such as
>      umask automake
>
Thanks for this suggestion.  It pointed me to the older patch I referenced
above.

>      umask directories "make install"
> However, I think it has usually been raised with maintainers of downstream
> packages, who are not equipped to fix it.  Nothing comes up when I search
> for umask on http://lists.gnu.org/archive/html/bug-automake/ .
> 
> Thanks a lot for your attention!
> 
> -jason
> 
> [*] Following the standard installation instructions leads to a silent
> failure of installation.  The cockeyed installation can result in
> mysterious error messages when you try to use it.  E.g., I got messages
> saying that the command-line utilities couldn't find their .so files.
> Fixing the mistaken permissions is also tricky.  Even if you figure out
> that your umask was at fault, you can't just change your umask and run
> "sudo make install" again.  That's because the directories already exist
> and rerunning "mkdir -p" on them is a no-op.  So you have to figure out
> which directories were created and chmod them manually.  I hope this makes
> clear why having some kind of fix is important ...
> 

Thanks,
  Stefano