[GRASS-dev] Directory security/permission issue
Glynn Clements
glynn at gclements.plus.com
Tue Jul 10 12:27:18 EDT 2007
Brad Douglas wrote:
> > > While looking over my working dirs, today, I noticed that all of my
> > > recent locations were created with 0777 permissions, instead of the
> > > traditional 0755 mask. Temp directories are still created properly.
> > >
> > > 0777 is bad form and a potential security problem.
> > >
> > > Is there a reason for the change I missed? A quick search through the
> > > archives didn't turn up anything.
> > >
> > > It seems to have come as an accidental result of the MINGW changes. The
> > > offending code can be found in lib/gis/paths.c in G_mkdir().
> > >
> > > This should be explained or corrected before 6.2.2 is released.
> >
> > The mode passed to mkdir is modified by the process' umask to obtain
> > the actual mode of the directory. If you're ending up with
> > world-writable directories, that implies that your umask is zero,
> > which is insecure.
> >
> > Your umask should normally be at least 0022, (or 0022 if you want
> > files to be group-writable, which is sometimes useful); if you're
> > paranoid, use 0077 (i.e. no permissions for anyone but yourself).
>
> umask...figures. Your lack of cerebral bitrot astounds me. I had
> completely forgotten about it and I, apparently, was too arrogant to
> look at a manpage. ;-)
>
> Don't know how, but my umask was set to 0002.
Odd; 0002 should give mode 775 for directories.
init sets it to 0002, and that will propagate to anything which
doesn't change it. It's quite common to set it in the bash startup
scripts (/etc/profile, ~/.bash_profile, ~/.bashrc etc).
If it's set in the "login" scripts (/etc/profile, ~/.bash_profile,
~/.bash_login), it may not take effect for X sessions. The X startup
scripts don't normally source those scripts, and bash will only source
them for a login shell (and xterm doesn't create a login shell by
default; use "-ls" or set "XTerm.vt100.loginShell: true").
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list