incorrect permissions on target install directories

[GoogleCodeExporter]

pdsh-2.28 doesn't explicitly set directory permissions appropriately.

account used to do 'configure' and 'make':

ssh-sdowdy$ umask
0077

account used to do the 'make install':

root# umask
0022

Consequently:

# pwd
/usr/local/pdsh-2.28
# find . -type d -ls
50497513    4 drwx------   6 root     root         4096 Nov  3 08:37 .
50497531    4 drwx------   2 root     root         4096 Nov  3 08:37 ./bin
50497515    4 drwx------   3 root     root         4096 Nov  3 08:37 ./lib
50497516    4 drwx------   2 root     root         4096 Nov  3 08:37 ./lib/pdsh
50497514    4 drwx------   2 root     root         4096 Nov  3 08:37 ./sbin
50497536    4 drwxr-xr-x   3 root     root         4096 Nov  3 08:37 ./man
50497537    4 drwxr-xr-x   2 root     root         4096 Nov  3 08:37 ./man/man1

looking at the 'make install' transaction log....

/usr/bin/install -c -d -m 0755 "/usr/local/pdsh-2.28/man/man1"
explains the (correct) perms on the man directories, but:

test -z "/usr/local/pdsh-2.28/bin" || mkdir -p -- "/usr/local/pdsh-2.28/bin"

explains how explicit perms aren't done on the bin directory.

Thanks,
--stephen

Original issue reported on code.google.com by stephen....@gmail.com on 3 Nov 2011 at 2:48

[GoogleCodeExporter]

Thanks, Stephen. I'll start taking a look at this now.
I can definitely reproduce this, but the "make install" 
code is auto-generated by automake, so this must have been
broken for a long time.

I wonder if rebuilding Makefile.in with a newer automake will
resolve this issue..

Original comment by mark.gro...@gmail.com on 11 Nov 2011 at 3:07

• Changed state: Accepted
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Are you sure that your umask was not 0077 at the time of 'make install'?

I don't have this problem when I do 'umask 0022; make install'

Original comment by mark.gro...@gmail.com on 11 Nov 2011 at 3:59

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

pdsh@googlecode.com wrote, On 11/11/2011 09:00 AM:

Mark,

Hmm, now i can't recall for sure, but...

configure/make phase was definitely done with my personal account with 
umask=0077

make install was done as 'root', which appears to be 0022 on this
system. (institutional default i'd like to change).  I don't recall
changing it, during the install process. so yeah, you're right that
it seems inconsistent that the 'mkdir' would change the perms.
(at this point i don't have an explanation.   I could try to 
reproduce the problem by running the build/install again...)

So, yeah, i can only get the dirs to be unreadable with UMASK 0077
so, i must have manually done that, though i don't remember it...

# find /usr/local/pdsh-2.28__testing/ -type d -ls
47555010    4 drwx------   6 root     root         4096 Nov 11 13:25 
/usr/local/pdsh-2.28__testing/
48540176    4 drwx------   2 root     root         4096 Nov 11 13:25 
/usr/local/pdsh-2.28__testing/bin
47555012    4 drwx------   3 root     root         4096 Nov 11 13:25 
/usr/local/pdsh-2.28__testing/lib
48351760    4 drwx------   2 root     root         4096 Nov 11 13:25 
/usr/local/pdsh-2.28__testing/lib/pdsh
47555011    4 drwx------   2 root     root         4096 Nov 11 13:25 
/usr/local/pdsh-2.28__testing/sbin
50145546    4 drwxr-xr-x   3 root     root         4096 Nov 11 13:25 
/usr/local/pdsh-2.28__testing/man
50145547    4 drwxr-xr-x   2 root     root         4096 Nov 11 13:25 
/usr/local/pdsh-2.28__testing/man/man1

Ultimately, i like to work with 0077 as 'root', which does often
bring up lots of problems in application source deployments.  It's
also a requirement in DoD/government/UNIX STIG/ work

IMHO a package that is intended to deploy to /usr/local, /opt,
/usr/bin, etc and intended to be used by 'mere mortals' (non-root
group/world) should explicitly set permissions as applicable on the
installed components, rather than relying on a umask value being
relaxed enough to pass through world read/exec bits.

Clearly the automake/makefile are "Doing The Right Thing(tm)" w.r.t.
the installed binaries, libs, etc, it seems to only be the creation
of the directory hierarchy that is using 'mkdir' instead of 'install
-d --mode' or 'mkdir;chmod', etc

I note that the aclocal.m4 has a macro AM_PROG_MKDIR_P that has some
interesting notes in it.   That seems to state that automake is going
to rely on the user having the umask they want to create directories
with set before running.  Again, i think that's a bad assumption
and i'm not familiar with automake, so don't know what the proper
way to make install directory hierarchies is, but if you want to
simply fall back on what i'm reading as automake's excuse for not
trying to "do the right thing" because it introduces issues, and
leaving it at a silent implication of "user burden" to set umasks
to get expected/desired behaviour, then it's fine to resolve this.

Original comment by stephen....@gmail.com on 11 Nov 2011 at 9:17

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

You have some good points, but I'm on the fence on this one.
I could see some people getting upset if 'make install' overrode
their current umask.

Since the current 'make install' code is managed by automake, I'm not
inclined to open that can of worms to try fixing it.

FWIW, we use umask 0077 for root as well. All our software is
installed by RPM however, so the packaging is responsible for
the permissions on various dirs. (I think most packages handle this
explicitly.)

Original comment by mark.gro...@gmail.com on 12 Nov 2011 at 2:09

• Added labels: ****
• Removed labels: ****