Linked by Thom Holwerda on Wed 5th Apr 2006 17:37 UTC, submitted by Mark
Linux "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."
Order by: Score:
File permissions
by Tom K on Wed 5th Apr 2006 18:42 UTC
Tom K
Member since:
2005-07-06

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.

Reply Score: 1

RE: File permissions
by hobgoblin on Wed 5th Apr 2006 20:49 UTC in reply to "File permissions"
hobgoblin Member since:
2005-07-06

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)...

Reply Score: 2

RE[2]: File permissions
by Tom K on Wed 5th Apr 2006 23:36 UTC in reply to "RE: File permissions"
Tom K Member since:
2005-07-06

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. ;-)

Reply Score: 1

RE[3]: File permissions
by hobgoblin on Thu 6th Apr 2006 12:16 UTC in reply to "RE[2]: File permissions"
hobgoblin Member since:
2005-07-06

now how did i forget about that...

Reply Score: 1

RE[2]: File permissions
by Ookaze on Thu 6th Apr 2006 09:55 UTC in reply to "RE: File permissions"
Ookaze Member since:
2005-11-14

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).

Reply Score: 1

RE[3]: File permissions
by hobgoblin on Thu 6th Apr 2006 12:15 UTC in reply to "RE[2]: File permissions"
hobgoblin Member since:
2005-07-06

well color me busted...

Reply Score: 1

RE[2]: File permissions
by Soulbender on Thu 6th Apr 2006 10:03 UTC in reply to "RE: File permissions"
Soulbender Member since:
2005-08-18

"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.

Reply Score: 1

RE[3]: File permissions
by hobgoblin on Thu 6th Apr 2006 12:14 UTC in reply to "RE[2]: File permissions"
hobgoblin Member since:
2005-07-06

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...

Reply Score: 1

RE[3]: File permissions
by Morin on Thu 6th Apr 2006 19:17 UTC in reply to "RE[2]: File permissions"
Morin Member since:
2005-12-31

> 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.

Reply Score: 1

ACLs are your friend
by anonymous.4n0nym0u5 on Wed 5th Apr 2006 19:45 UTC
anonymous.4n0nym0u5
Member since:
2006-04-05

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.

Reply Score: 1

a recommended read
by raver31 on Wed 5th Apr 2006 20:32 UTC
raver31
Member since:
2005-07-06

for all the people around here who think Linux will be hit hard with virus/trojans/spyware in the future.

Reply Score: 2

RE: a recommended read
by davematthew on Wed 5th Apr 2006 23:29 UTC in reply to " a recommended read"
davematthew Member since:
2006-04-05

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.

Reply Score: 1

RE: a recommended read
by Soulbender on Thu 6th Apr 2006 03:01 UTC in reply to " a recommended read"
Soulbender Member since:
2005-08-18

"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.

Reply Score: 0

RE[2]: File permissions
by Dima on Thu 6th Apr 2006 07:22 UTC
Dima
Member since:
2006-04-06

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.

Reply Score: 1

RE[3]: File permissions
by jaboua on Thu 6th Apr 2006 13:35 UTC in reply to "RE[2]: File permissions"
jaboua Member since:
2005-09-08

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)"

Reply Score: 1

RE[2]: a recommended read
by captain_knobjockey on Thu 6th Apr 2006 07:58 UTC
captain_knobjockey
Member since:
2005-08-23

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

Reply Score: 2

RE[3]: a recommended read
by Soulbender on Thu 6th Apr 2006 09:36 UTC in reply to "RE[2]: a recommended read"
Soulbender Member since:
2005-08-18

"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

Reply Score: 1

RE[4]: a recommended read
by jaboua on Thu 6th Apr 2006 13:38 UTC in reply to "RE[3]: a recommended read"
jaboua Member since:
2005-09-08

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.

Reply Score: 1

RE[5]: a recommended read
by Morin on Thu 6th Apr 2006 19:30 UTC in reply to "RE[4]: a recommended read"
Morin Member since:
2005-12-31

> 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.

Reply Score: 1

RE[5]: a recommended read
by Soulbender on Fri 7th Apr 2006 02:54 UTC in reply to "RE[4]: a recommended read"
Soulbender Member since:
2005-08-18

"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").

Reply Score: 1