umask help [SOLVED]

[Woodchuck]

On Fri, 25 Aug 2006, George Goodman wrote:

> Hello Dave,
>
> Thanks for the pointers...
>
>> I've tried like hell to duplicate this problem, but cannot on
>> a default 3.9 system.  However, I have had it in the past.
>> 
>> I conclude that your problem is that you have an /etc/profile
>> file and that a umask of 0 or something else 'bad' is set therein.
>
> Ok, I looked through the various profile and .profile files on the
> system. I find one .profile in / and another in /root. I am certain
> the one in /root is the one that is having the effect because it is
> where I have set the editor, and that is working.

I have been able to duplicate the problem by having commented-out
umasks in my /root/.profile.

This line in .profile is enough to cause the problem:

#umask 002

This will give the error msg "root umask is group writeable"

#umask 000

gives both errors.

Even

#umask

gives both errors.

This line
# this is a comment using the word umask without a number

gives both errors.

This line

#fumask

gives the errors.

So does

# This file written by Fred Fumasker

OK, the problem is in the second awk script, where it is going through
the .profile and /etc/profile files.

Actually the problem arises in the grep command immediately before
the awk script.

The line is
 	                egrep umask $i |

It succeeds if it finds the string "umask" anywhere in the file.
It then feeds the found line(s) to awk; awk assigns the tokens
$1, $2, ... $n  to the tokens of the line, then the awk script
fails to verify that token $1 is "umask" and that token $2 is
an octal number... it assumes they are.

If you look earlier in the script, some other hacker made a better
try with the csh scripts.  his grep line is

 		if egrep -q '[[:space:]]*umask[[:space:]]' $i ; then
                         umaskset=yes
 		fi

But then he does nothing at all with "umaskset" until later, when
he uses it to decide whether to suppress the output of the awk
script or not.  But this is still bogus, in its way.  The egrep
command will search for the first occurence of
 	[[:space:]]*umask[[:space:]] in the file and if
it matches, we will see the errors, because that regular expression,
in plain English says

 	"zero or more spaces the 'umask' then at least one space"

Note that it is *NOT*
 	"beginning of line, zero or more spaces..."

In other words it matches comments like

# any text at all umask

(that line has a trailing blank ... hard to see, eh?)

Also the -q on the egrep command means "stop looking after the
first occurence and report success".

So....

Bottom line, there are two action items:

(1) Go through all the files that are relevant (scan through
/etc/security for them) and eliminate all occurences (commented or
not, part of other strings or not) of the string "umask" except for
active, current settings of umask.  If it is important that these
strings remain, change them to "UMASK" or something like that.

2) Write up a bug report without flamage for OpenBSD.

2b) I looked at /etc/security in NetBSD... it is better, different.
The csh path files are checked for umask in a sane manner, and at
first glance may work as advertised.  The sh path, while different
from Open's also appears to have its own, unique bugs.  *sigh*

So do (1), and I'll think about doing (2) and maybe (2b).

Dave