Re: 1.8 and mkdir_p

[Harlan Stenn <hstenn at cisco dot com>]

Howdy Alexandre,

> Happy new year. 

Thanks, and same to you.

> >>> "Harlan" == Harlan Stenn <hstenn@cisco.com> writes:
> 
>  Harlan> This change:
>  Harlan> - Makefiles will prefer `mkdir -p' over mkinstalldirs if it is
>  Harlan> available.  This selection is achieved through the Makefile
>  Harlan> variable $(mkdir_p) that is set by AM_INIT_AUTOMAKE to either
>  Harlan> `mkdir -m 0755 -p --', `$(mkinstalldirs) -m 0755', or 
>  Harlan> `$(install_sh) -m 0755 -d'.
> 
>  Harlan> sucks flaming red bugs.
> 
> I did this because someone complained that if the installer had
> umask=077, the installation could create directories which were
> not world readable.

But what if that is what the installer intended?

> http://sources.redhat.com/ml/bug-automake/2003/msg00190.html
> (Note that the patch in the follow-up is not what has been applied.)
> 
> Since we are ignoring umask when installing files, it sounded
> correct to ignore it too when installing directories.

I kinda understand that.

How about we make a way for folks to specify/override the mode for directory
creation and "file" (script, bin, data, whatever) installation?

> Another point is that there are places in Automake where we have
> to use `install_sh' even if `install' exists, because `install'
> does not create leading directories by default and Automake
> cannot create mkdir calls for directories it does not know
> before hand (e.g., AC_SUBSTed nobase_ files).  `install_sh' is
> slow, and in the future we would like to use `install -D'
> instead when it is supported.  However `install -D' always
> creates 755 directories (it will preserve special bits like SGID
> though) and has no option to change that.

That will be Really Bad for us, as we go to great lengths to make sure we
create group-writable directories.

>  Harlan> How can one change the '-m 0755'?  I haven't found
>  Harlan> anything about this in the docs.
> 
> perl -pi -e 's/-m 0755//g' configure

I made a local patch to the script that installs automake's macros that
pretty much does that...  We need this to be a "locally permanent" change
because we automate our checkouts and builds.

> sorry

I understand.

>  Harlan> I have a case where we want SGID and group-write.  In
>  Harlan> the "old days" this was easy - the previous case simply
>  Harlan> did whatever it did and we got SGID by default (because
>  Harlan> the parent directory was SGID) and our umask setting
>  Harlan> got us group-write.
> 
> This looks like a legitimate setup to me.  More legitimate than
> umask=077 for installers, at least :)  Right now I think it's
> better to remove all these `-m 0755' from Automake.

That's what I did here...

> However, I'd really like to hear opinions about the related
> issues:
> 
>  - is it normal to honor umask when creating directories and not 
>    when installing files?

I guess this depends on who you ask[1].

>  - should we just drop the `install -D' idea (because it creates
>    755 directories regardless of umask)?

That would be my vote.

Thanks...

H

[1] There are people who think a config.guess output that says:

 i686-pc-linux-gnu

is "normal", while some of us feel that is a particularly useless value and
would prefer to see something like:

 i686-pc-redhat7.3

instead, just like the original documentation spec'd out.

I have a script that does things like:

 rh> cvo
 CVO=i686-pc-redhat7.3
 CVO_CPU=i686
 CVO_KOSVER=2.4.20-20.7.cisco.4smp
 CVO_OS=redhat7.3
 CVO_OSNAME=redhat
 CVO_OSVER=7.3
 CVO_VENDOR=pc
 CVO_raw=i686-pc-linux-gnu
 rh> cvo I am a @cvo@ machine
 I am a i686-pc-redhat7.3 machine
 rh>

 sb> cvo
 CVO=sparc-sun-solaris2.8
 CVO_CPU=sparc
 CVO_KOSVER=Generic_108528-17
 CVO_OS=solaris2.8
 CVO_OSNAME=solaris
 CVO_OSVER=2.8
 CVO_VENDOR=sun
 CVO_raw=sparc-sun-solaris2.8
 sb>

which lets me do things like make sure I have a particular kernel OS version
on some platforms where that is appropriate.

But I've mentioned this before in other places...

H