[Gllug] File permissions and umask on Ubuntu (and I think probably, Debian)

[damion.yates at gmail.com]

On Sat, 6 Jan 2007, John Winters wrote:

> John Winters wrote:
> [snip]
> > Still investigating.
> 
> Found it!  It's a long-standing and well-documented (but alas
> un-fixed) bug in gdm.  Whatever your system configuration it
> overrides it and forces you to 0022.
> 
> Once I'd worked out it was only happening when I logged in through
> gdm, the rest was easy.  Thank you for listening (seriously).

This is unlikely to remain the only bug relating to umask/mode on
writing files to the shared space.  Any application that creates files
or directories, from the latest fileshareing tool to a word processor,
could have been coded with a mode* which forces permissions that won't
permit later alterations by others.  Or just as you found, a new login
session manager could do silly things with default umask, messing up
correctly behaved apps.  In addition there is always the risk that a
user could explicitly alter their umask, if they have been playing or
believe they're increasing their account security.

I'm pretty sure I remember saved files in some apps which I've then
found have been set with no access group and other (rw------- when my
default umask is 022).  Obviously there are also cases where apps
explicitly do a chmod after they have finished, like scp -rp, tar or
cp -a.

I have worked in an environment where we used a shared space and I
have to say, the only way it worked was because the vast majority of
users were technically competant enough to remember to chgrp and chmod
after writing.  Yes g+s saved the hassle of needing to chgrp things
but sometimes the files could have been extracted from a tar.  This
was an old solaris system with the equivalent of a users group so few
people would willingly to have a umask of 002.

Before I started looking in to extended ACLs on directories to force
modes on files which I suspect would be an elegant way to do it.  I
came up with a solution that is guarenteed to work for your needs.
That is to make sure the filesystem forces group write on any created
object.  This is easily done if you use for example, a vfat
filesystem.  I've tested with a loopback file /home/share.dat issued
"mkdosfs /dev/loop0" then mounted with:
mount -t vfat -o umask=0,gid=1003 /dev/loop0 /home/share
A chmod fails to succeed even if try and create something that isn't
"root:sales / rwxrwx---" (1003 = sales).

Obviously this would be nicer tied in to specific directories, or
using auto growing loopback filesystems at a push.  I suspect some
options to the ext3 mount, or code additions, or some kludgy FUSE
based mountable filesystem looping back in to a directory but simply
lacking chmod() functionality would work too.

Enjoy!

Damion

* from man creat:
       int creat(const char *pathname, mode_t mode);
 ...
  the  permissions  of  the  created file  are  (mode  &  ~umask).   

So as this is logical AND, it doesn't matter that your umask is 002 if
the app is written to be silly.

-- 
Damion Yates - damion.yates at gmail.com
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug