Subject: "sudo make install" applies umask to new directories
From: Jason Eisner <[email-masked]>
To: [email-masked]
Date: Fri, 3 Aug 2012 00:06:50 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

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