Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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
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...
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
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
# set UMASK
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
<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>
Distribution: K/Ubuntu 12.04/14.04, Scientific Linux 6.3/6.4, Android-x86, Pretty much all distros at one point...
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...
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.
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.