[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jason Eisner
Subject: bug#12130: "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!


[*] 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 ...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]