@sansp00 wrote:
Sure, having work on Unix system for the past 10 years, I got to know my way around a bit (even if I am just a programmer, not a tech …)
The permission go as this:
digit 1:user who owns
digit 2:user in the group
digit 3:other user not in the group
digit 4:all userPatrick S.
Mostly, but the first digit has to do with suid/sgid. The ones you see in ls are the last three digits.
The permission blocks are made of three sections. One for owner, one for members of the owning group, and the other for everyone.
So when you see permissions on a file like:
rw-rw-r–
That means the owner of the file has read/write permissions. Anyone who is a member of the group that owns the file has read/write permissions. Everyone else has read permissions. Makes sense, ya?
Okay. If you wanted to, you could think of those permissions a a list of permissions that are flagged as off or on. In the case above, you could think of the permissions as toggles, right? Like, you could think of the permission from left to right as “on, on, off, on, on, off, on, off, off”. You could represent that more simply with a 1 or 0 for on or off:
110110100
When it’s written like that, there is a easy-to-see typographical isomorphism between that and rw-rw-r–. Cool. So what?
Well, the obvious thing to do (for cs people, anyway 🙂 is to represent those as numbers rather than binary digits. The numbers break apart logically in groups of three, so it makes sense (again, from a cs standpoint) to group them numerically as one digit per group of three. (if you were bored, or a math geek, you would see that it means that the maximum digit range would be 0-7, or would mean that this was a base-8 number system. Octal! Neat!)
So breaking into groups of three, you have:
110 110 100
Or, translating from binary to decimal:
664
Which is a lot more concise. If you spend a second playing with the numbers, you’ll see what the individual digits are:
7 is read/write/execute
6 is read/write
5 is read/execute (you pretty much have to have r to x)
4 is read only
3 is write/execute (which doesn’t make sense, and you won’t see it)
2 is write only (which again, doesn’t make much sense, and you wont’ see it)
1 is execute only (which you don’t generally see either)
Good so far?
Up to here, you’ve probably already figured out. There are a couple things worth noting at this point that you probably haven’t seen or figured out yet. These points are:
1. There is no “delete” permission. Instead, that’s controlled by write permission on the parent directory. So if the directory is 775, and the file is 666, (and I’m not the owner or a member of the owning group), then I can’t delete the file. I can overwrite or truncate the file, though, as I have write permissions to it.
2. The x permission is execute for files, but on directories, it means to allow traversal. So again, if I’m a “everyone else” user, and a directory is 774, implying I have read permission to the folder, it won’t matter, because I can’t cd to it. I can’t see what is in the directory because I don’t have permissions to traverse the directory. No x. So a directory that is 444, which would seem to imply world readable actually isn’t. That’s why you see 7s and 5s in directory permissions. Along with the r, you *have* to have x. Not sure why, that’s just how it is.
Okay. that’s the last three, and the first digit is the most confusing. That deals with setuid, setgid and the sticky bit.
Files (and directories) can be flagged as setuid, setgid, or sticky. Those bits can be represented in octal just like the permissions, as flags for setuid, setgid, and sticky.
010, for example means setuid off, setgid on, sticky off.
That’s the first number in chmod. So “chmod 2775” means:
set permissions to rwxrwxr-x, and make the folder setgid.
Great. So what do those bits do?
Sticky is the easiest. On executables, it means don’t flush the application pages when the program exits. Keep them pinned in memory. In old systems that were starved for memory, and there were particular programs that were run nearly continuously, it might make sense to keep a program completely in memory to reduce startup thrashing when the program started. Nobody uses this anymore, as disk speeds are higher, memory paging is cheaper, and we aren’t in 1985 anymore.
The sticky bit on folders, though, is still useful. It means that only the owner can delete or rename files. So, for example, on the /tmp directory, you might want to allow everyone to read and write in the folder, but don’t want somebody deleting anyone elses temp files. You could do that (and frequently you’ll see your system *does* do this) by setting the stick bit on the /tmp directory:
chmod 1777 /tmp
Without the sticky bit, anyone could delete anything in there, even if it wasn’t their file.
Okay. So now setgid and setuid.
setuid is the easiest, so let’s look at that. One frequent problem early on in unix was having programs that needed access to the system, but users didn’t have permissions to access those features. Think of a cd burning program. Users generally don’t have write access to physical disks, so things like cd burning programs wouldn’t work for them. It would work for root, since root has access to it, but there needed to be a way for users to run a program as a user with more permissions. That’s what setuid does for executables. If you have a file that’s owned by root, and the setuid bit is set, then whenever the program is run (by anyone that has permissions to run the program), then the program gets run as the root user.
Make sense? In the case of the cd burner, if the program was owned by root and setuid, then anyone that ran the program would run it as root, and then they would have the permissions to access the devices they need to.
Sadly, it also means that people can exploit the program to do various damage, so setuid root programs are few and far between, but still, that’s the original intention. Well, not entirely few and far between: http://www.securityfocus.com/bid/24953/info
Still, if you look around your system, you might find some simple programs that are setuid. traceroute and ping for example.
Some systems interpret the suid bit on directories to mean that any files saved in the directory should be owned by the user that owns the parent directory.
As far as sgid goes, that’s the middle bit. That’s like the suid bit, except for the group. That doesn’t make much sense in the case of executables, but for directories it does. When the sgid bit is set, then any file saved in a folder is owned by the group that owns the folder.
That’s handy. If you have multiple users adding files to the same directory and they belong to multiple groups, it’s possible they could save files in a folder that belong to a group that others don’t have. So files that one user makes in a shared folder could end up being non-writeable by other users that have read/write permissions in the folder:
So sgid on a folder makes sure that the group membership is preserved, making sure that future additions to the folder maintain the same permissions as the files already in there.
Okay, this is already turning into a tutorial, so I’m going to close this out, but that’s what the first octal digit is. setuid, setgid, and sticky bit.