[debbugs-tracker] bug#12130: closed ("sudo make install" applies umask to new directories)

[GNU bug Tracking System]

Your message dated Mon, 17 Sep 2012 06:44:00 -0600
with message-id <address@hidden>
and subject line Re: bug#12130: Fwd: bug#12130: "sudo make install" applies 
umask to new directories
has caused the debbugs.gnu.org bug report #12130,
regarding "sudo make install" applies umask to new directories
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
12130: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12130
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> "sudo make install" applies umask to new directories
>
>
>
>
> Date: 
>
> Fri, 3 Aug 2012 00:06:50 -0400
>
>
>
>
> 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 ...
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask to new directories Date: Mon, 17 Sep 2012 06:44:00 -0600 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature

--- End Message ---