[SOLVED] Inheriting file permission

abhinav4 · 09-27-2012, 08:56 AM

Is there a way to inherit parent folder permission?
There is a folder called "/stuff" with 777 permission, which means everyone has full access to the file.
Now if someone creates a file inside "/stuff" i want that file to inherit the permission from its parent ie. file should have permission of .777

JaseP · 09-27-2012, 09:11 AM

I found this article, which addresses this...
http://techblog.shanock.com/articles...of-a-directory

And another;
http://backdrift.org/recursive-inoti...ng-with-lsyncd

And a Q&A from another site;
http://superuser.com/questions/15191...rent-directory

The short answer is there's no pervasive, yet easy way to do this... But there's more than one way to skin a cat. The other options are to use use SAMBA or a partition that has no permissions, like FAT16 or FAT32...

Using SAMBA, is probably the best bet... But that comes with it's own case of canned worms...

tronayne · 09-27-2012, 09:39 AM

Quote:

Originally Posted by abhinav4

Is there a way to inherit parent folder permission?

Well, no, not automagically.

You have granted Attila the Hun permission on the directory, so users can write into it, but a file written in that directory will be owned by the user and have the users' UMASK.

The default, system-wide, UMASK is 0022 which is -rw-r--r-- 1 userid users for files and drwxr-xr-x 2 userid users for directories.

If you really want all users to have read-write access to all other users' files, you can set the UMASK value in their individual .profile file (in their home directory) like this

Code:

# set UMASK
umask 002

which will set the value when they log in and cause any file they write (every file, always) to -rw-rw-r-- 1 userid users, which permits group read-write permission. That may not be what you want when you think about it, eh? And you do not want to do this system-wide, it's a vast security hole.

A simple way to accomplish this requires a little user education. In this case you would not put the umask 002 in their .profile files; rather, teach them that, when they are going to write a file in that directory to

Code:

umask 002
cd directory
                        <do what you need to do>
                        <either log out or>
cd                      <takes you to your home directory>
umask 022               <change back to the default UMASK>

That's the safest.

Hope this helps some.

JaseP · 09-27-2012, 10:11 AM

Changing the system-wide UMASK is inadvisable, as tronayne implied. You could potentially break things that you are unaware of (for instance, if you use NIS, your keyfiles could get all [explitive implied]-ed up). There are strange things out there in packages that you don't know about. And changing the local UMASK doesn't necessarily solve your problem either.

I am dubious of "user education." I couldn't get my own wife to stop breaking the system on one of our HTPCs (her nickname in the house is; "The Breaker of All Things"). It was a simple setup, with a SAMBA share to the server, and a file manager set to display ripped movies as if it were a menu... I even locked the user interface up by changing the read-write permissions of configs... But she still managed to break it. Users are the definition of entropy. I now run a more locked down system, more appliance or kiosk-like.

A script (maybe run as a cron job), or using something like SAMBA is probably better (although SAMBA's potentially overkill). It depends on what you're trying to do...

jschiwal · 09-27-2012, 10:53 AM

You can use setfacl to create a default acl for the directory. The default will be inherited. Using a group such
as "users" that regular users belong to might be better than "others".

Code:

setfacl -m o:rwx directory
setfacl -m d:o:rwx  directory

Files created won't have the x bit set, but shouldn't. For globally writable directories, the sticky bit should be set, and the partition should be mounted with the nosuid,noexec and nodev options. You could use a bind mount to mount a directory there instead of a partition,
and include these mount options. This allows you to use better options even if you hadn't dedicated a partition for it.

Shanock · 10-14-2012, 05:37 PM

Sorry to necrobump, but I'm the author of the first article that JaseP cited (came across this thread while looking at my Google Analytics data). It seems as though he may have stopped reading where I mentioned Samba, but if you read the rest, you'll find that Samba didn't work out too well for me, and I now use a much better (slimmer, simpler, and more reliable) solution involving inotifywait.

It will watch a directory for activity and perform any action you want on a created/modified/accessed file, including setting both permissions and ownership. This will do exactly what you want, though the example on my page will only work on one directory (recursively) at a time. If you want something more complicated (i.e., any file created in /home will have appropriate ownership relative to userdir in which it was created), it can be done with inotifywait, but will take some scriptwork.

suicidaleggroll · 10-14-2012, 05:58 PM

You could also set up a cron job for root to chmod -R that directory every so often.