request for feature: umask control with GNU make
Fabien COELHO
Hi GNU folks!
As I'm working within a group on a project, it sometimes happens that
someone creates a file without the proper umask for a collaborative
work. I was wondering how I could control the umask for files generated
thru make. I think that a special UMASK macro, as there is a special
SHELL macro for instance, would do the job properly for me. Sure I can
define
SHELL = umask 007 ; /bin/sh
But I think that a special UMASK macro that would apply to the make
process would make sense. Also I'm not sure that the SHELL macro is always
used. Also it might make sense to suggest a GROUP macro so that a newgrp is
performed automatically if set (sure, this can be done by setguid the
directories).
Hope this help. Have a nice day,
Fabien.
Fabien COELHO __ http://www.cri.ensmp.fr/~coelho __ coe...@cri.ensmp.fr
CRI-ENSMP, 35, rue Saint-Honoré, F-77305 Fontainebleau cedex, France
phone: (+33|0) 1 64 69 {voice: 48 52, fax: 47 09, standard: 47 08}
________ All opinions expressed here are mine _________
Paul D. Smith
fc> As I'm working within a group on a project, it sometimes happens that
fc> someone creates a file without the proper umask for a collaborative
fc> work. I was wondering how I could control the umask for files generated
fc> thru make.
The typical method is to create a shell script that sets up your
environment, then invokes make. There are a number of advantages you
can leverage with this method, besides just umask setting.
fc> I think that a special UMASK macro, as there is a special SHELL
fc> macro for instance, would do the job properly for me.
I'm not dismissing this idea out-of-hand, but it's quite far down on the
list of things to do--and I'd have to think more about whether it's a
good thing for make to do or not.
I'd suggest going with the shell script route (or whacking the GNU make
source yourself) for the time being.
fc> Sure I can define
fc> SHELL = umask 007 ; /bin/sh
Have you tried this? It won't work. The SHELL variable is expected to
be the command that runs a shell script; it's simply exec'd directly.
You can't make the invocation of the shell a shell script _itself_;
that's a serious catch-22 :)
fc> Also it might make sense to suggest a GROUP macro so that a newgrp
fc> is performed automatically if set
Performing a newgrp would require make to be setuid root; that's not
something I'm comfortable with at all. Very, very difficult to do
right.
If you need this I suggest you change make to be setgid the group you
want (I didn't try this but I think it will work).
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
Fabien COELHO
>>>>> On 06 Aug 1998 09:43:45 -0400, psm...@BayNetworks.COM (Paul D. Smith) said:
fc> As I'm working within a group on a project, it sometimes happens
fc> that someone creates a file without the proper umask for a
fc> collaborative work. I was wondering how I could control the umask
fc> for files generated thru make.
Paul> The typical method is to create a shell script that sets up your
Paul> environment, then invokes make. There are a number of
Paul> advantages you can leverage with this method, besides just umask
Paul> setting.
Hum... If you do something like that in a "make" script, it means that it
will apply at every invocation, while I was looking for something that
would only occur when invoked in some directories.
fc> I think that a special UMASK macro, as there is a special SHELL
fc> macro for instance, would do the job properly for me.
Paul> I'm not dismissing this idea out-of-hand, but it's quite far
Paul> down on the list of things to do--and I'd have to think more
Paul> about whether it's a good thing for make to do or not.
Sure.
Paul> I'd suggest going with the shell script route (or whacking the
Paul> GNU make source yourself) for the time being.
fc> Sure I can define
fc> SHELL = umask 007 ; /bin/sh
Paul> Have you tried this?
Yes.
Paul> It won't work.
It does for me with GNU Make version 3.75 under Linux 2.0.31: You might
consider this a bug, but I like the feature. You can document it;-) What
annoys me is that the make documentation says that SHELL may not be used
sometimes, thus my request.
coelho:staff(027)@coulommiers ~/tmp; cat Makefile
UMASK = 002
SHELL = umask $(UMASK); /bin/sh
foo:; $(RM) $@.tmp ; touch $@.tmp ; /bin/ls -l $@.tmp
coelho:staff(027)@coulommiers ~/tmp; gmake foo
rm -f foo.tmp ; touch foo.tmp ; /bin/ls -l foo.tmp
-rw-rw-r-- 1 coelho staff 0 Aug 6 16:03 foo.tmp
coelho:staff(027)@coulommiers ~/tmp; gmake UMASK=022 foo
rm -f foo.tmp ; touch foo.tmp ; /bin/ls -l foo.tmp
-rw-r--r-- 1 coelho staff 0 Aug 6 16:03 foo.tmp
coelho:staff(027)@coulommiers ~/tmp; gmake UMASK=072 foo
rm -f foo.tmp ; touch foo.tmp ; /bin/ls -l foo.tmp
-rw----r-- 1 coelho staff 0 Aug 6 16:03 foo.tmp
Paul> The SHELL variable is
Paul> expected to be the command that runs a shell script; it's simply
Paul> exec'd directly.
Sure. That does not prevent ";" to be used, depending on what is used for
the exec (system(), exec??()...). Maybe it can depend on whether some sh
conf file is read which might reset the umask, but I think usually sh does
not source much files when launched.
Paul> You can't make the invocation of the shell a shell script
Paul> _itself_; that's a serious catch-22 :)
Ah? But unix does not always allow to change the shell use for an exec
with system(). Hence what is really done by make might be /bin/sh (by
system) to interpret both SHELL and the arguments?
fc> Also it might make sense to suggest a GROUP macro so that a newgrp
fc> is performed automatically if set
Paul> Performing a newgrp would require make to be setuid root; that's
Paul> not something I'm comfortable with at all. Very, very difficult
Paul> to do right.
I thought unix could allow a process to fork to a different group if the
user can do so.
Thanks,
Paul D. Smith
fc> Hum... If you do something like that in a "make" script, it means
fc> that it will apply at every invocation, while I was looking for
fc> something that would only occur when invoked in some directories.
Well, if you only want it in some subdirectories you could put the umask
command in the recursive make invocation. You might also have to put it
into your script--maybe you could put a special file in those
subdirectories that contained the umask or something, and use that in
both your wrapper script and the recursive make invocations.
I'm just spouting here :)
fc> Sure I can define
fc> SHELL = umask 007 ; /bin/sh
fc> It does for me with GNU Make version 3.75 under Linux 2.0.31: You might
fc> consider this a bug, but I like the feature. You can document it;-)
Wow. I checked the code and it does handle this correctly; it realizes
that SHELL isn't a simple command and invokes a shell to handle SHELL.
So, what you're really running here is basically:
/bin/sh -c 'umask 007; /bin/sh -c "...cmd..."'
Crazy!
You'll probably get slightly better performance by using exec, like
this:
SHELL = umask $(UMASK); exec /bin/sh
to save yourself an extra fork.
fc> What annoys me is that the make documentation says that SHELL may
fc> not be used sometimes, thus my request.
If you do as above, SHELL will _always_ be used. SHELL is only not used
if GNU make can gaurantee the results with or without it would be
exactly the same. If you define SHELL to be this complex, obviously
that's never going to be true. Make will always choose to use a shell
(if it didn't, you'd get an error since it would be trying to directly
exec() the command "umask 002; ...", which obviously wouldn't work).
So, this will actually always work for you.
Paul> The SHELL variable is expected to be the command that runs a
Paul> shell script; it's simply exec'd directly.
fc> Sure. That does not prevent ";" to be used, depending on what is
fc> used for the exec (system(), exec??()...).
When I said "exec'd", I meant exec'd; as in, it does its own fork() and
exec() (execvp() in this case).
Paul> You can't make the invocation of the shell a shell script
Paul> _itself_; that's a serious catch-22 :)
fc> Ah? But unix does not always allow to change the shell use for an exec
fc> with system(). Hence what is really done by make might be /bin/sh (by
fc> system) to interpret both SHELL and the arguments?
GNU make doesn't use system() on UNIX. Ever.
fc> Also it might make sense to suggest a GROUP macro so that a newgrp
fc> is performed automatically if set
Paul> Performing a newgrp would require make to be setuid root; that's
Paul> not something I'm comfortable with at all. Very, very difficult
Paul> to do right.
fc> I thought unix could allow a process to fork to a different group
fc> if the user can do so.
No; you can chgrp a file to any group in your group ID list, but in
order to change your process's GID you need to run the setgid() call,
and that's available only to root (or else you can only change to your
real or saved GID). Check the man pages for setgid().
For example, if you look at your system you'll see that the newgrp
program is setuid root.
At least, this is the way it works on all UNIX systems I'm aware of.
Fabien COELHO
fc> SHELL = umask 007 ; /bin/sh
Paul> So, what you're really running here is basically:
Paul> /bin/sh -c 'umask 007; /bin/sh -c "...cmd..."'
Paul> Crazy!
You mean Great;-)
Paul> You'll probably get slightly better performance by using exec,
Paul> like this:
Paul> SHELL = umask $(UMASK); exec /bin/sh
Paul> to save yourself an extra fork.
Ok.
fc> What annoys me is that the make documentation says that SHELL may
fc> not be used sometimes, thus my request.
Paul> If you do as above, SHELL will _always_ be used. SHELL is only
Paul> not used if GNU make can gaurantee the results with or without
Paul> it would be exactly the same. If you define SHELL to be this
Paul> complex, obviously that's never going to be true. Make will
Paul> always choose to use a shell (if it didn't, you'd get an error
Paul> since it would be trying to directly exec() the command "umask
Paul> 002; ...", which obviously wouldn't work).
Paul> So, this will actually always work for you.
Ok. thus my feature is basically there, at the price of a few forks and
execs which could be avoided with an integrated UMASK macro, but most
important I can rely on it.
Well, thanks for having fixed gmake so quickly for me;-)