GNU bug report logs - #12130
"sudo make install" applies umask to new directories

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12130 in the body.
You can then email your comments to 12130 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jason Eisner <jason <at> cs.jhu.edu>
To: bug-automake <at> gnu.org
Subject: "sudo make install" applies umask to new directories
Date: Fri, 3 Aug 2012 00:06:50 -0400

[Message part 1 (text/plain, inline)]

Hi automake folks,

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.

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.

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.

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 or a y/n prompt when the current
umask (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 can't understand why make install
treats directory permissions inconsistently with file permissions.  And I
can't see why a single-user preference like a umask should be reflected in
a global installation.

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
     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 ...

[Message part 2 (text/html, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jason Eisner <jason <at> cs.jhu.edu>
To: bug-automake <at> gnu.org
Subject: Re: "sudo make install" applies umask to new directories
Date: Fri, 3 Aug 2012 00:20:41 -0400

[Message part 1 (text/plain, inline)]

Followup -- see this thread from 2004:
    http://www.digipedia.pl/usenet/thread/16496/9413/

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 ...)

-jason

[Message part 2 (text/html, inline)]

Message #11 received at 12130 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jason Eisner <jason <at> cs.jhu.edu>
Cc: 12130 <at> debbugs.gnu.org
Subject: Re: bug#12130: "sudo make install" applies umask to new directories
Date: Tue, 07 Aug 2012 19:32:21 +0200

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

Message #14 received at 12130 <at> debbugs.gnu.org (full text, mbox):

From: Jason Eisner <jason <at> cs.jhu.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12130 <at> debbugs.gnu.org
Subject: Re: bug#12130: "sudo make install" applies umask to new directories
Date: Fri, 10 Aug 2012 05:22:44 -0400

[Message part 1 (text/plain, inline)]

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/
>
> 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 ...)


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.

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

[Message part 2 (text/html, inline)]

Message #17 received at 12130 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jason Eisner <jason <at> cs.jhu.edu>
Cc: 12130 <at> debbugs.gnu.org
Subject: Re: bug#12130: "sudo make install" applies umask to new directories
Date: Fri, 10 Aug 2012 11:47:52 +0200

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

Message #20 received at 12130 <at> debbugs.gnu.org (full text, mbox):

From: Jason Eisner <jason <at> cs.jhu.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12130 <at> debbugs.gnu.org
Subject: Re: bug#12130: "sudo make install" applies umask to new directories
Date: Fri, 10 Aug 2012 08:43:25 -0400

[Message part 1 (text/plain, inline)]

On Fri, Aug 10, 2012 at 5:47 AM, Stefano Lattarini <
stefano.lattarini <at> gmail.com> wrote:

> 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.
>

When is the next major version?  I'm guessing that a mere docfix won't help
existing packages because they are unlikely to replace their documentation
when they rerun automake (?).

> 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.
>

Perhaps.  But if you wish to preserve backward compatibility, that appears
to require some degree of inconsistency (as is typical).  In particular, it
will require treating umask differently on files and directories, because
that is what has been done in the past.  Making the behavior consistent
seems likely to break backward compatibility.  If we start honoring umask
on everything, that will break a large number of existing installation
habits or scripts that relied on install to use 644 on files.  If we start
ignoring umask on everything, that will break a smaller number of existing
installation habits or scripts that relied on a more permissive umask on
directories (i.e., the guy who complained in 2004).

The only ways I can see to make it consistent between files and directories
are to use the "OR" solution for both, or to ignore umask by default but
have a command-line flag on "sudo make install" that says "please respect
my umask" (for the few users who want to rely on it to get nonstandard
installation permissions at their site).

[Message part 2 (text/html, inline)]

Message #23 received at 12130 <at> debbugs.gnu.org (full text, mbox):

From: Jason Eisner <jason <at> cs.jhu.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12130 <at> debbugs.gnu.org
Subject: Fwd: bug#12130: "sudo make install" applies umask to new directories
Date: Tue, 21 Aug 2012 00:46:39 -0400

[Message part 1 (text/plain, inline)]

On Fri, Aug 10, 2012 at 8:43 AM, Jason Eisner <jason <at> cs.jhu.edu> wrote:

> The only ways I can see to make it consistent between files and
> directories are to use the "OR" solution for both, or to ignore umask by
> default but have a command-line flag on "sudo make install" that says
> "please respect my umask" (for the few users who want to rely on it to get
> nonstandard installation permissions at their site).
>

Better idea:

Have default 644 for files and 755 for directories, but let the user
override this by explicitly specifying any of
* the desired file permissions
* the desired directory permissions for newly created directories
* the desired group owner for newly created files and directories
via command-line options on "make install".

The 644/755 default is consistent and will work right for almost everyone.
But the command-line flag is useful for users who want to install with
different conventions.  I like this better than a 1-bit flag that says
"please respect my umask."

-jason

[Message part 2 (text/html, inline)]

Message #26 received at 12130 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Jason Eisner <jason <at> cs.jhu.edu>
Cc: 12130 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask
	to new directories
Date: Tue, 21 Aug 2012 14:55:55 +1000

On 08/21/2012 02:46 PM, Jason Eisner wrote:
> Better idea:
>
> Have default 644 for files and 755 for directories, but let the user 
> override this by explicitly specifying any of
> * the desired file permissions
> * the desired directory permissions for newly created directories
> * the desired group owner for newly created files and directories
> via command-line options on "make install".
>
>
You can already do this. You can, e.g., install packages with

make install MKDIR_P="mkdir -p -m 700"

Cheers,
Peter

Message #29 received at 12130 <at> debbugs.gnu.org (full text, mbox):

From: Jason Eisner <jason <at> cs.jhu.edu>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 12130 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask to
	new directories
Date: Wed, 22 Aug 2012 02:20:06 -0400

[Message part 1 (text/plain, inline)]

On Tue, Aug 21, 2012 at 12:55 AM, Peter Johansson <trojkan <at> gmail.com> wrote:

> On 08/21/2012 02:46 PM, Jason Eisner wrote:
>
>> Better idea:
>>
>> Have default 644 for files and 755 for directories, but let the user
>> override this by explicitly specifying any of
>> * the desired file permissions
>> * the desired directory permissions for newly created directories
>> * the desired group owner for newly created files and directories
>> via command-line options on "make install".
>>
>>
>>  You can already do this. You can, e.g., install packages with
>
> make install MKDIR_P="mkdir -p -m 700"
>

Good!  So then, why not correct the default for new directories to 755, as
originally proposed?

cheers, jason

[Message part 2 (text/html, inline)]

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: didi <diogofsr <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask to
	new	directories
Date: Fri, 14 Sep 2012 09:29:03 +0000 (UTC)

Peter Johansson <trojkan <at> gmail.com> writes:

> 
> On 08/21/2012 02:46 PM, Jason Eisner wrote:
> > Better idea:
> >
> > Have default 644 for files and 755 for directories, but let the user 
> > override this by explicitly specifying any of
> > * the desired file permissions
> > * the desired directory permissions for newly created directories
> > * the desired group owner for newly created files and directories
> > via command-line options on "make install".
> >
> >
> You can already do this. You can, e.g., install packages with
> 
> make install MKDIR_P="mkdir -p -m 700"

Unfortunately this doesn't seem to work properly, as the parent directories
still retain the permissions of the user.

$ mkdir -p -m 755 foo/bar

drwx------ foo/
drwxr-xr-x bar/

Message #35 received at 12130 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: didi <diogofsr <at> gmail.com>
Cc: 12130 <at> debbugs.gnu.org, coreutils <at> gnu.org
Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask
	to new directories
Date: Mon, 17 Sep 2012 09:53:52 +1000

[CC coreutils this is 
http://lists.gnu.org/archive/html/bug-automake/2012-08/msg00001.html]

On 09/14/2012 07:29 PM, didi wrote:
>> You can already do this. You can, e.g., install packages with
>> >  
>> >  make install MKDIR_P="mkdir -p -m 700"
> Unfortunately this doesn't seem to work properly, as the parent directories
> still retain the permissions of the user.
>
> $ mkdir -p -m 755 foo/bar
>
> drwx------ foo/
> drwxr-xr-x bar/
>
>
>
>
Hi Didi,

That was unexpected and unfortunate IMVHO. I see the same behaviour on 
my local system, in other words,

mkdir -p -m 700 /tmp/foo/bar

creates bar with permissions 700 and bar with 776 (my umask). I wonder 
is that behaviour is mandated by some standard or if there is room for 
improvement in coreutils here (CC:ed).

Thanks,
Peter

Message #42 received at 12130-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 12130-done <at> debbugs.gnu.org, coreutils <at> gnu.org, didi <diogofsr <at> gmail.com>
Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask
	to new directories
Date: Mon, 17 Sep 2012 06:44:00 -0600

[Message part 1 (text/plain, inline)]

tag 12130 notabug
thanks

On 09/16/2012 05:53 PM, Peter Johansson wrote:

> mkdir -p -m 700 /tmp/foo/bar
> 
> creates bar with permissions 700 and bar with 776 (my umask). I wonder
> is that behaviour is mandated by some standard

Yes - POSIX requires this:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

-p
    Create any missing intermediate pathname components.

    For each dir operand that does not name an existing directory,
effects equivalent to those caused by the following command shall occur:

    mkdir -p -m $(umask -S),u+wx $(dirname dir) &&
    mkdir [-m mode] dir

    where the -m mode option represents that option supplied to the
original invocation of mkdir, if any.

> or if there is room for
> improvement in coreutils here (CC:ed).

Since POSIX requires the existing behavior, there's unfortunately no
room for improvement, and I'm closing this as not a bug in coreutils.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.