[clug-talk] File permissions: add but not modify/delete?
maillist at digital-adrenaline.com
Mon Nov 29 15:22:48 PST 2004
I accidently deleted the first message here. What you want to do is have a
directory where users can add files, and read them, but not write or delete
to them after they're in there, right?
So The directory should be 777, and the file should be 400 (or 444 is everyone
should be able to read the files).
I'd do it like this...
chmod 777 /path/to/directory.
This is easy.
Then, and most semi-recient distros will support this on EXT3 or ReiserFS.
I've never used any other file systems.
setfacl -R -d -m u::r /path/to/directory
setfacl -R -d -m g::r /path/to/directory
setfacl -R -d -m o::r /path/to/directory
This should do what you need. The -R means recursive. You might not need
this, but it will let you similarly lock up subdirectories too. -d means
Default. So it won't affect the current settings, but anything created there
going forward will be similarly affected. -m means modify. Then there are
U[ser], G[roup], and O[ther] two colons, since we aren't going to specify a
particular user, group, etc, and then the permission we want to have granted,
which is read. that could be any of rwx.
According to my reading, you should be able to set a mask to accomplish this,
but it has never worked for me. YMMV. If you thought permissions were a
black art, just wait until you play with ACLs. And then, just for giggles,
toss Samba into the mix.
getfacl /path/to/directory will show the current ACLs. You will notice that
if something has an ACL, it will have a + after the permissions when you ls
-alh (or whatever). So expect to see -r--r--r--+ rather than just
Hope that helps.
On Friday 26 November 2004 18:08, Curtis Sloan wrote:
> On Fri November 26 2004 17:25, William Astle wrote:
> > You can force the group of the files in the directory to match the group
> > of the directory by setting the SGID bit. If the SUID bit worked
> > similarly for directories, you could use that to accomplish what you
> > wanted from the user owning the file perspective. It doesn't behave that
> > way, though. Even with that, however, you would still have the umask
> > problem; whatever the user sets the umask to still applies to the file
> > after it was created so if the user's umask allows group write/read on
> > the file, they'll still be able to read/modify the file (even if they
> > can't delete it).
> > All nice and straightforward, eh?
> Actually, yes, that makes sense. I forgot about some *nix permissions
> fundamentals and now that I've been reminded it all fits into place.
> Fortunately, it's not a big deal that the user not be able to modify
> created files this time. So sticky bits will do nicely (I've never
> actually used them before, so this will be a good excuse to practice).
> Thanks to everyone who contributed.
> Curtis S.
> clug-talk mailing list
> clug-talk at clug.ca
> Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
> **Please remove these lines when replying
More information about the clug-talk