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.
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).
In general, the permissions specified by a program when calling
open(), mkdir(), etc should be the maximum which the user might
possibly want (i.e. 0777 for directories and executable files, 0666
for non-executable files), as the umask can only remove permissions,
not add them.
On Mon, 2007-07-09 at 22:25 +0100, Glynn Clements wrote:
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.
> > 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").
On Tue, 2007-07-10 at 17:27 +0100, Glynn Clements wrote:
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.
I know. I figured that at one point, the umask must have been 0, but
after some further testing, all new directory permissions are 0777
REGARDLESS of manual change to umask. This leads me to believe it is
getting set somewhere in GRASS. Maybe lib/init/set_data.c?
This does not happen when a new location is created when already in the
GRASS shell (r.in.gdal).
I also noticed that Fedora has recently changed /etc/bashrc to set the
umask to 0002 for normal users.
> > Don't know how, but my umask was set to 0002.
>
> Odd; 0002 should give mode 775 for directories.
I know. I figured that at one point, the umask must have been 0, but
after some further testing, all new directory permissions are 0777
REGARDLESS of manual change to umask. This leads me to believe it is
getting set somewhere in GRASS. Maybe lib/init/set_data.c?
lib/gis/gisinit.c has umask(022), while the others all have umask(0).
Every single one of these is wrong. The umask is for the user;
programs should leave it alone.
lib/gis/gisinit.c has umask(022), while the others all have umask(0).
Every single one of these is wrong. The umask is for the user;
programs should leave it alone.
Glynn Clements wrote:
> Also, lib/init/init.sh had two occurrences of:
>
> echo "umask 022" >> "$bashrc"
>
> which I have removed.
any g.access repercussions to this? (beyond the obvious)
> The remaining occurrence:
>
> tmp=/tmp/grass6-$USER-$GIS_LOCK
> (umask 077 && mkdir "$tmp") || {
>
> has been retained, although I'm not sure why this doesn't just use
> "mkdir -m 007" rather than (temporarily) setting the umask.
