http://www.osnews.com/story/14241/Understanding_File_Permissions Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Sun, 19 May 2013 01:01:37 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://www.osnews.com/thread?111893 http://www.osnews.com/thread?111893 When I first started playing around with Linux (I think I was 14), I was pretty confused about file permissions. I was used to the NTFS way of doing things (ACLs, which I still consider superior), where a particular file system object had "users" attached to it, and then each user was assigned a list of permissions. There was then an "Everyone" catch-all.

Over time, I've come to like UNIX-style permissions, and if I were to give anyone a hint towards understanding them, it'd be to always focus on the owner of the file first. Work your way down from there.

Granted, it's still tricky to do things like "This and that group should be able to write to this directory, but not read any files once they're there, whereas this group should have full read/write access", but as long as you start from the owner and think creatively, eventually it'll all click. Wed, 05 Apr 2006 18:42:00 GMT donotreply@osnews.com (Tom K) Comments http://www.osnews.com/thread?111928 http://www.osnews.com/thread?111928 Managing file permissions by user/group/other access quickly becomes tedious with a large number of users, who do not fall into a single group. Enter ACLs - getfacl(1) and setfacl(1) help enormously. Solaris has had ACLs for a while (2.6?) and it's good to see Linux has them now as well. Wed, 05 Apr 2006 19:45:00 GMT donotreply@osnews.com (anonymous.4n0nym0u5) Comments http://www.osnews.com/thread?111966 http://www.osnews.com/thread?111966 for all the people around here who think Linux will be hit hard with virus/trojans/spyware in the future. Wed, 05 Apr 2006 20:32:00 GMT donotreply@osnews.com (raver31) Comments http://www.osnews.com/thread?111983 http://www.osnews.com/thread?111983 thats why all unixes have hard links. basicly create two dirs side by side and have one be a hard link to the other. then you give group 1 write access to one dir, and group 2 read/write access to the other dir.

hell, you can even put then in totaly diffrent areas of the filesystem if you like

now i would agree that if ACL only came with the read/write/execute options thats used in most basic unix file systems, they would be superior. but the current list of options in windows is:

for a folder:
full control
modify
read & execute
list folder content
read
write

for a file:
full control
modify
read & execute
read
write

ok so maybe that modify option can be a nice thing to have, but under unix again the hard link comes into play. a hard linked file is only removed ones all the links are deleted. want to make sure a file isnt accidentaly deleted? hard link it into some other area of the drive

as for read vs read & execute, i have no idea. i was supposed to learn the diffrence at one time, but it looks like the info didnt stick...

basicly most of the seperate option up there can be recreated in unix using hard links and comboes of RWX (or 777 if you want to be a pain in the ass)... Wed, 05 Apr 2006 20:49:00 GMT donotreply@osnews.com (hobgoblin) Comments http://www.osnews.com/thread?112042 http://www.osnews.com/thread?112042 Yes, what a useful article! I've always been confused with anything beyond the rwx and finally understand now what the s and t mean and how to use them in a production environment! It's nice having everything so coherently laid out. Wed, 05 Apr 2006 23:29:00 GMT donotreply@osnews.com (davematthew) Comments http://www.osnews.com/thread?112046 http://www.osnews.com/thread?112046 Yeah, like I said, it requires creativity and thinking. It's possible, but not quite as easy as ACLs.

BTW ... ever click the "Advanced" button in the NTFS permissions dialog? There are a lot more neat little permissions there. ;-) Wed, 05 Apr 2006 23:36:00 GMT donotreply@osnews.com (Tom K) Comments http://www.osnews.com/thread?112117 http://www.osnews.com/thread?112117 "for all the people around here who think Linux will be hit hard with virus/trojans/spyware in the future."
This really hasnt got anything at all to do with if/when Linux will be hit hard by viruses or spyware. Thu, 06 Apr 2006 03:01:00 GMT donotreply@osnews.com (Soulbender) Comments http://www.osnews.com/thread?112176 http://www.osnews.com/thread?112176 basicly create two dirs side by side and have one be a hard link to the other.

What? Have you actually tried that yourself? You can't hardlink directories!

basicly most of the seperate option up there can be recreated in unix using hard links and comboes of RWX

If you need more advanced/fine-grained permissions than user/group/others... Then, um, why not just use ACLs? That's why Linux supports them too, you know. Thu, 06 Apr 2006 07:22:00 GMT donotreply@osnews.com (Dima) Comments http://www.osnews.com/thread?112180 http://www.osnews.com/thread?112180 clearly you did not comprehend the article. what raver31 was saying, was that people on here automatically think that when linux gets as many users as windows, then it will get the same amount of malware,
however, as the article plainly shows, there is the file permission "defenses" that it has to get around first.

do some research first buddy Thu, 06 Apr 2006 07:58:00 GMT donotreply@osnews.com (captain_knobjockey) Comments http://www.osnews.com/thread?112189 http://www.osnews.com/thread?112189 "as the article plainly shows, there is the file permission "defenses" that it has to get around first."

It's not a defense again spyware or viruses. Please try to understand the issues at hand. While file system permissions is a perfectly working defense against users modifying or accessing files they have no business with, it does not provide a defense against spyware or certain kind of viruses.
You see, not all malware is designed to screw up your box, it would be counter-productive for them. What they want is just to be able to run an application, any application, as an unprivilieged user, ie as you. They just sit unnoticed in the background, relaying huge amounts of spam or participating in botnets. Wrecking your box by screwing with system files would only draw unnecessary attention to their existance.Edited 2006-04-06 09:37 Thu, 06 Apr 2006 09:36:00 GMT donotreply@osnews.com (Soulbender) Comments http://www.osnews.com/thread?112195 http://www.osnews.com/thread?112195 thats why all unixes have hard links

Hard links don't work on directories.

now i would agree that if ACL only came with the read/write/execute options thats used in most basic unix file systems, they would be superior

People love to say ACL are superior, but that's not true. What they mean is that ACL can do more complicated things, but they are also incidentally more complicated to manage. This does not mean ACL are superior, it depends on the situation. For home usage, even advanced home usage like I do (with LDAP and all), ACL are clearly inferior. I don't even install them in the kernel.

want to make sure a file isnt accidentaly deleted? hard link it into some other area of the drive

That works pretty well. You just have to make sure the file won't be modified instead (but backups are there for that). Thu, 06 Apr 2006 09:55:00 GMT donotreply@osnews.com (Ookaze) Comments http://www.osnews.com/thread?112197 http://www.osnews.com/thread?112197 "now i would agree that if ACL only came with the read/write/execute options thats used in most basic unix file systems, they would be superior"

I disagree. ACL's are superior only in certain scenarios, but for most uses the simpler permissions are better. Thu, 06 Apr 2006 10:03:00 GMT donotreply@osnews.com (Soulbender) Comments http://www.osnews.com/thread?112216 http://www.osnews.com/thread?112216 what i was thinking was that you could have more then one specific user or group with RWX settings pr file or dir, as thats mainly what i think is the usefullness of most ACLs, and why people sometimes dont like the simpler unix way... Thu, 06 Apr 2006 12:14:00 GMT donotreply@osnews.com (hobgoblin) Comments http://www.osnews.com/thread?112217 http://www.osnews.com/thread?112217 well color me busted... Thu, 06 Apr 2006 12:15:00 GMT donotreply@osnews.com (hobgoblin) Comments http://www.osnews.com/thread?112219 http://www.osnews.com/thread?112219 now how did i forget about that... Thu, 06 Apr 2006 12:16:00 GMT donotreply@osnews.com (hobgoblin) Comments http://www.osnews.com/thread?112242 http://www.osnews.com/thread?112242 From ln --help:
" -d, -F, --directory allow the superuser to attempt to hard link
directories (note: will probably fail due to
system restrictions, even for the superuser)" Thu, 06 Apr 2006 13:35:00 GMT donotreply@osnews.com (jaboua) Comments http://www.osnews.com/thread?112243 http://www.osnews.com/thread?112243 Well... A virus is something that infects the system and screws it up...

But malware may have a hard time as well, if it's left without executable permissions. Thu, 06 Apr 2006 13:38:00 GMT donotreply@osnews.com (jaboua) Comments http://www.osnews.com/thread?112366 http://www.osnews.com/thread?112366 > I disagree. ACL's are superior only in certain
> scenarios, but for most uses the simpler permissions
> are better.

I would even go as far to say that standard Unix-like permissions are overkill for most cases. The problem is rather to make it possible to use a simple policy if possible, and a complex one if necessary, in the *same* system. Thu, 06 Apr 2006 19:17:00 GMT donotreply@osnews.com (Morin) Comments http://www.osnews.com/thread?112379 http://www.osnews.com/thread?112379 > But malware may have a hard time as well, if it's left without executable permissions.

Specially forged data files do not have executable permissions but execute code anyway through buffer overflow attacks.

Not all scripting interpreters require the script to have executable permissions. The script could also be embedded in a datafile.

Social engineering attacks don't have a hard time in making the user set executable permissions.

... and so on. You can of course pretend the problem doesn't exist. But you could also understand the cause of these problems, why file permissions alone *don't* handle them, and find a better solution. This doesn't mean file permissions are useless - in fact they'd probably play an important role in a proper solution. But they are not a solution to everything if taken alone.

On a side note, many "computer specialists" avoid responsibility for social engineering attacks altogether, probably with excuses such as "people shouldn't be so stupid", or "we can't solve this problem anyway", or "we aren't the right people to solve this problem", or whatever. Saying that file permissions solve the malware problem tends to lead in the same direction. Thu, 06 Apr 2006 19:30:00 GMT donotreply@osnews.com (Morin) Comments http://www.osnews.com/thread?112509 http://www.osnews.com/thread?112509 "A virus is something that infects the system and screws it up..."
No, a virus is something that infects a system and uses it to spread further. Damaging the infected system is not always a goal.

"But malware may have a hard time as well, if it's left without executable permissions."
Not really, since the owner of a file always can change its permissions and a file can still be run even if it doesnt have the execute permission (ie "/bin/sh somescript"). Fri, 07 Apr 2006 02:54:00 GMT donotreply@osnews.com (Soulbender) Comments