“In GNU/Linux, file access is restricted. Users don’t necessarily have the same rights when it comes to deleting, executing or even reading files. In fact, every file contain data such as its owner, its permissions and other information which defines exactly what can be done with it, and by whom.”
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.
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)…
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. 😉
now how did i forget about that…
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).
well color me busted…
“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.
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…
> 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.
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.
for all the people around here who think Linux will be hit hard with virus/trojans/spyware in the future.
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.
“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.
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!
<br/>
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.
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)”
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
“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
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.
> 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.
“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”).