CHMOD - A bit of clarity please [Archive]

View Full Version : CHMOD - A bit of clarity please

H3LL

19th July 2009, 04:09 AM

Nick Bogaerts

19th July 2009, 08:21 AM

The extra one is for SUID, SGID and sticky, apparently, though I'm not sure how they relate to the sections owner/group/public.

SUID stands for Set User ID. It allows a user to execute a program with it's owner's permissions rather than their own. Typically you'd want to use it to make sure a file can only be modified via a specific program. SGID (Set Group ID) is the same, but with the group's permissions. I don't think there's ever a situation on a web site where you'll want SUID and SGID bits set (let alone the Execute flags).

The sticky bit is only meaningful directories, it allows only the owners of files inside the directory (and superusers) to delete them.

Which digit in the sequence are they? I'm guessing the first but I'm not sure.

Also, I'm making the assumption that SUID=4, SGID=2 and sticky=1 but that's purely a guess and I can't find a confirmation on that.

So, for example, does 7 = SUID.SGID.sticky and 6 = SUID.SGID.not-sticky?

Correct.

Exactly how secure are these settings? How cautious should one be?

You should be very careful with SUID and SGID, since they lead to privilege escalation. The sticky bit isn't usuallly relevant to websites.

Wudang

19th July 2009, 08:53 AM

You might find it easier just issueing the character format
eg chmod u+w to give the owner write permission
Not bad guide here http://en.wikipedia.org/wiki/Chmod#Command_line_options

ddt

19th July 2009, 09:24 AM

I've been using CHMOD for files on websites for ages but realise that I don't really know what I'm doing (or have forgotten). Please note that I use an FTP GUI and not command line. I don't want to go there just yet.

What I think I know:

Change mode sets file/directory permissions for (from left to right) Owner, Group and Public/Others.

Permissions can be set to one or all of either r-Read, w-Write or x-Execute (Search permission when set for directories).

Each setting has a numeric value; r=4, w=2 and x=1

Add them together to set the values you want. e.g. 7 = rwx, 4= r--, 6 = rw- and 1 = --x

If I have CHMOD set for a file to 644 that would mean that the owner can Read and Write to the file (6), the group can only Read the file (4) and others/public can only Read the file (4). Nobody can Execute the file.

Rule of thumb; if it's an odd number it can be executed, even numbers, it cannot.

In other applications you may see 644 displayed as rw--r--r- or 777 displayed as rwxrwxrwx somewhere.
All correct.

Where it all gets a bit vague:

My FTP client has four settings so 7777 is a valid entry.

The extra one is for SUID, SGID and sticky, apparently, though I'm not sure how they relate to the sections owner/group/public.

The Interweb tubes are not really helping much but I'm guessing they are something more server related but not sure what.

Which digit in the sequence are they? I'm guessing the first but I'm not sure.

Also, I'm making the assumption that SUID=4, SGID=2 and sticky=1 but that's purely a guess and I can't find a confirmation on that.

So, for example, does 7 = SUID.SGID.sticky and 6 = SUID.SGID.not-sticky?

Exactly how secure are these settings? How cautious should one be?

So if anyone can clarify CHMOD in an FTP client GUI for me in simple, not-too-techy language and correct any assumptions that are wrong, I would be very grateful.

The thread might also be useful for those that throw in CHMODs of 644, 777 or 0777 just because they are told to but not really knowing why.

Also correct. To add to Nick's explanation: in a web-context, I don't see much relevance of these three permissions for files you're storing on a webserver. Mostly, you'll be concerned that your files are accessible to the webserver program (Apache, most of the times). You store your files there under ownership of, say, user 'h3ll', and Apache runs as user 'apache' or some such (and with different groups), so you're mostly concerned that the read-permission for others is turned on. You definitely don't want the write-permission to be on.

There's two cases where you want the execute-permission on.

One is when you're using "Server Side Includes", which is a simple way to make dynamic webpages. Apache recognizes which HTML-files have to be processed for Server Side Includes by the x-bit being on (depends on how Apache has been configured, but it's a popular setting to do it like that).

The other case is, of course, when you really have a program - commonly called a CGI-script in web-context - you're uploading. Then Apache has to be able to execute your CGI-script, and the x-bit has to be on. If you want that CGI-script to be able to access your private data, then I can see a use for the SETUID-bit. Say, your CGI-script is some game and you keep a high-score list in a file only you can access on the webserver. Then if the CGI-script normally is executed by Apache, it runs with the permissions of the user 'apache' and can't access the high score list. However, if you turn on the SETUID-bit, it will run with permissions of 'h3ll' and can access your high score list. That's the only case I can imagine the SETUID-bit to be useful in this context. And, as Nick said, be very very careful with it.

Nick left out one meaning for the SGID-bit, for directories, which is worth mentioning. Under Unix, a user may belong to multiple groups - one of which is his 'primary group'. Now, when a user creates a new file or directory, it will belong to the primary group. If you want the file to belong to another group, you have to issue a separate 'chgrp' command. When you change the group ownership of a directory, say to 'group2', and then set the SGID-bit on the directory, subsequently all files that are created in that directory will also automatically belong to 'group2'. Additionally, if you create a subdirectory, it will also have the SGID-bit set, so that this trickles down to files in the subdirectory too. I can't think of a useful example for the context of a website, btw.

Lastly, the whole number system for permissions is considered 'obsolescent'. All Unixes I know of still accept it, but for use on the command-line it is considered better form to use the newer, symbolic notation:
chmod a+r file1 file2 file3 ...
This means: turn on ("+") the read-bit ("r") for all kinds of users ("a"). The advantage is that it doesn't affect the other permissions not mentioned in the command-line - while, with the number notation, you set all permissions simultaneously.

The notation for the permissions consists of three characters:
1) for whom: "u" for user (owner), "g" for group, "o" for others, "a" for all
2) how: "+" for "turn on", "-" for "turn off", "=" for "set exactly like this"
3) which: "r" for read, "w" for write, "x" for execute, "s" for setuid/setgid, "t" for sticky.

So you could do something like this:
chmod a+r,go-x file1 file2 file3
which turns on all r-bits, turns off the x-bits for group and others, and leaves all other permission bits untouched, whatever they were on all three files.

I don't know anything about GUI ftp-clients, so don't know if they can work like this too, or whether they are still in the stone age (this symbolic notation is at least 20 years old, but somehow the numbers seem to persist in all kinds of instructions. Aargh.)

shadron

19th July 2009, 09:41 AM

The header of every file in a UNIX -derived system has a 16 bit word reserved in it to hold these "permission bits". Starting from the right, there are the three bits for controlling all-other access, three bits for group access, and three bits for owner access. The owner and the group owner of the file are defined in other places in the file header. For FTP and web work the only ones that are genrally used are owner (usually the webmaster) and the all-others, which is everyone else. However, maintenance of the files on the UNIX system (such as backup and such) may be done through group permissions, so they can't just be zeroed out and neglected. The three bits define, as you stated above, whether the owner/group/all others have specific read/write/execute permissions on the file. Read means the ability to access the file at all; write means the ability to change the file's contents, and execute is the ability to pass control to a file and execute it; this would be limited to binary executables and scripts for various interpretors, such as shell scripts and so on.

Note that UNIX systems treat directories just like any other file. They have the same permissions except that the execute bits take on a new meaning - "execution" of a directory means the ability to use it as a directory. That is, you can only search a directory if you have permissions to do that, as defined by the execute bits. Without them, the directory is treated as just a file; you cannot access the files within it at all - can't even see if they exist. Further, the ability to erase a file depends not on the permissions of the file itself, but rather on the permissions of the directory it is contained in. So while you might not be able to access a file at all (it's read/write/execute permissions are all zero), you still may be able to delete it, if its directory has read and write permissions available to you.

The SUID, SGID and sticky bits are independent from this series of nine bits, and have separate meanings. SUID (set user ID) bit says that whenever a user executes this file (the permissions are favorable, and the user actually does sexecute) then during that execution the owner ID is set to the file's owner, not whoever he really is. This is generally used to allow a low level user to have high level permissions (like, say, root, which is the highest permission available) only while running this executable. Needless to say, this can be dangerous, and this only user at the higher level is allowed to turn on the SUID bit for an executable, and he should only do so for totally trusted executable files. SGID says the same thing for group permissions. The sticky bit is not used by any UNIX web server as far as I know; it has meaning only if you are a UNIX user.

For the actual bit values of the identifiers, look in chmod.h file in /usr/include, or google for chmod.h:
#define SUID 04000
#define SGID 02000
#define SVTX 01000
#define RUSR 00400
#define WUSR 00200
#define XUSR 00100
#define RGRP 00040
#define WGRP 00020
#define XGRP 00010
#define ROTH 00004
#define WOTH 00002
#define XOTH 00001
#define ALLM 07777 /* all octal mode bits */

In general, as an ftp uploader to a UNIX server, you need to (almost always) set the permissions of html, image and other normal files to 644. If the file is meant to be executed (as a server-side script, like .cgi, .php and so on) then set them to 755. Set directory permissions to 755.

In this role you should never be concerned about SUID, SGID or sticky bits.

EDIT: Just saw ddt's explanation. Between the messages here, you should be able to pretty much piece things together about UNIX permissions.

H3LL

20th July 2009, 01:49 AM

Ducky

20th July 2009, 02:07 AM

Excellent stuff.

Thanks everyone for the long and informative posts.

Not only have you explained exactly what I asked for but now a lot of the CHMOD stuff on the Internet now makes sense whereas it was somewhat incomprehensible/confusing before.

Thanks again.

Which means you're closer to getting this joke:

find . -name "your\ base" | xargs chown -r us:us

(ETA: Perhaps I should have scripted that joke with chmod, not chown. Meh, you'll get it eventually.)

H3LL

20th July 2009, 02:19 AM

Zero Wing - AYBABTU.

:D

.

Ducky

20th July 2009, 04:51 AM

Zero Wing - AYBABTU.

:D

.

Then there is:

> cd /home/your\ base/; ps -ef | grep "your\ doodz" | xargs kill -9

ddt

20th July 2009, 05:30 AM

Note that UNIX systems treat directories just like any other file. They have the same permissions except that the execute bits take on a new meaning - "execution" of a directory means the ability to use it as a directory. That is, you can only search a directory if you have permissions to do that, as defined by the execute bits. Without them, the directory is treated as just a file; you cannot access the files within it at all - can't even see if they exist. Further, the ability to erase a file depends not on the permissions of the file itself, but rather on the permissions of the directory it is contained in. So while you might not be able to access a file at all (it's read/write/execute permissions are all zero), you still may be able to delete it, if its directory has read and write permissions available to you.
It's a bit more subtle than that, and maybe it's interesting to delve a bit into how the Unix filesystem works. Unlike, say, the FAT filesystem, a Unix directory does not contain all info on a file. A Unix directory only contains the names of the files and their so-called "inode number", which is an internal number by which Unix can find the rest of the attributes of the file - like its owner, its permissions, its size, etc., and where its contents are stored. Now the R-bit on a directory gives you the right to see its contents: the names of the files.

A fun experiment to do is to give yourself only the R-permission on a directory of your own (which I'll name "subdir") and then do the command 'ls subdir'. You'll see the files listed. Then try 'ls -l subdir' - which also asks for (most of) its attributes. You'll see the error message "Permission denied". To see those, you need the X-bit, which I'd call the "right of traversal" in case of a directory. So, you have to give yourself the X-bit as well to see those. To make even more fun, now turn off the R-bit, so you only have the X-permission. You do remember the name of one of those files (say: "afile")? Then type 'ls -l subdir/afile' and you see that it works :) - so when you know the name of a file in a directory, and you have the right of traversal into that directory, you can access the attributes of that file.

Then let's turn to the W-bit. It's worth repeating that the W-bit for files means: "the right to alter the contents of an existing file" - so it's not the right to create or delete files. But then, what is creating a file? It means you add its name to a directory; likewise, deleting a file means erasing its name from a directory. So for creating or deleting or renaming a file, you need the W-bit on the directory, since you then alter the contents of the directory. However, for all of those actions, you also need to access (one of) the attributes of the file in question, so you also need the X-bit (more on this below). The W-bit on a directory is completely useless without the X-bit.

So, the X-bit on a directory (which you can nick the "right of use", or the "right of traversal") is the most important right on a directory; without it, you can't do much else.

The sticky bit

Let's now also turn to the sticky bit. On a Unix system, there are several directories (notably the directory /tmp) which are meant for everyone to store temporary files. The "temporary" means nothing to Unix internally, btw, but there are lots of programs that need to create a file for the duration of the execution of the program, and delete it when they're done - that's what is meant here by temporary. For instance, both the KDE and the GNOME desktop environments do so.

The permissions on such a directory then are rwxrwxrwx, or 777: everybody can do everything. However, this means that, say, user 'h3ll' can create a (temporary) file and, regardless of the permissions on that file, user 'ddt' then can remove that file. That wouldn't be nice, would it? I could screw up your desktop that way. So that's the reason why they invented the sticky bit for directories. When the sticky bit is set, only the owner of the file or the owner of the directory can remove a file from the directory.

Hard links

You might be left with the question: why do you need to access a file's attributes when you want to delete it anyway? Well, deleting isn't always deleting :). I mentioned above in passing that Unix internally finds a file by means of its "inode number" - the "inode" is the structure on disk which contains the file's attributes and the pointer(s) to the file's contents. You can see those inode numbers with 'ls -i', but there are hardly commands which can use it. The structure I described above makes it possible that you give the same file multiple names - and indeed, there's a Unix command which exactly does that. When you have a file called "firstname", you can issue the command
ln firstname secondname
and you'll see that secondname is indeed a second name for the same file. The command 'ls -l' shows they have identical attributes, and when you really check with 'ls -i', you see they have the same inode number - so they are, indeed, two names for the same file. You may also have noticed the second column of the 'ls -l' output. That second column contains a (small) number, and mostly it's 1. However, now it says '2' for your file "firstname" alias "secondname". That column is called the "link count": the number of names you've given to a file.These names don't even have to reside in the same directory - they can, in principle, be anywhere. In Unix parlance, making a second name for a file is called making a "hard link". The "link count" - you already guessed - is indeed another attribute that is stored with the file.

There's nothing to distinguish those two (or three, or four, or ...) names from each other: Unix does not remember which is older, or which is the original name. So now, what happens when you type:
rm firstname
is that only that name is removed from the directory contents. The file still has another name, so the file still exists - but is, from now on, only accessible through the name "secondname". And you'll see that the link count has dropped back to 1.

When you now, subsequently, also remove the name "secondname", Unix will see that the link count of the file is 1, so you're removing the last name of the file. After that, the file will be inaccessible, so at that point, Unix will actually remove the file from the filesystem.

So that's the reason that you need the X-bit when removing a file. When you remove a file, you actually (at first) don't remove a file but rather a filename, and you have to adjust the link count of the file - which is one of the attributes of the file.

(Note: making "hard links" is not possible for directories. Unix relies on the fact that the directory structure is strictly a tree. If you could make a "hard link" for a directory, you could also make a loop in the directory structure, and you can see that all kinds of mischief could come from that.)

Wudang

20th July 2009, 05:54 AM

Nice one, ddt.

ddt

20th July 2009, 07:46 AM

Nice one, ddt.
Thanks! I used to do training in this stuff. :) Well, let's do the symbolic links for completeness' sake, plus a bonus on hard links.

Link count of a directory

There's a nice property about the link count of a directory that's worth mentioning. I said you can't make hard links for directories - but the system does. Let's see how. For the experiment, go to a directory that doesn't have too many files in it (a dozen or so maximum - just so the output of the commands doesn't scroll off your screen).

Issue the command 'ls -al' (*). Right at the top, you'll see a directory with the name "." - a single dot. Remember its link count (say, 5) - we'll come back to that. Now we're going to make a subdirectory with the command:
mkdir subdir
and when you again issue the command 'ls -al', you see you have created a subdirectory. But the mkdir command has made more than that; just look into the subdirectory with
ls -al subdir
and you see it has two files in it, named "." (one dot) and ".." (two dots). Files - no, they're actually directories, as the lines begin with a "d". This is a package deal: when you create a directory, you create those two entries in it. The entry "." is a hard link to itself; the entry ".." is a hard link to its parent directory. They're part of what keeps the filesystem tree together. Now, issue again the command
ls -al
and look at the link count of "subdir". It is 2, because we've created two names for the new directory: it is called "subdir" in its parent directory, and it's called "." in itself.

Then look at the link count for "." - which we now know, is the directory we're standing in. That link count has increased by one - from 5 to 6. Remember that the new subdir had an entry called "..", which points to its parent directory? Yes, that's the new name. So, when a directory has a link count of 6, it means it has 4 subdirectories.

(*) the "-a" option with the ls command is needed here to display all files with names starting with a "."

Symbolic links

In my previous post, I mentioned that you cannot make hard links for directories, only for ordinary files. That's a pity: if you have this/really/deep/dir/struc/ture, and you get tired of typing that long name, you'd like to have a shortcut. I also said that you can make a hard link from another directory, and there I cheated a bit - I'll come back to that below.

Therefore, Unix has a second kind of links, called "symbolic link" or "symlink" for short. You make a symlink with the same command as a hard link:
ln -s firstname secondname
but note the "-s" option (for symbolic, of course). When you now issue an 'ls -l', you see you have created a new file "secondname". That file has a new file type, denoted with the letter "l" at the start of the line ("l" for symlink, screw consistency :)). Its permissions are rwxrwxrwx. At the end of the line is written: "secondname -> firstname". This symlink really is like a roadsign, saying "Amsterdam is to the left"; it has no contents of its own. You may note it has a size - to be precise, 9 in this case - and that's the length of the filename it points to.

For all "normal" Unix commands, a symlink is transparent. If you want to display the contents of the file, you can type
cat secondname
and it will print the contents of the file firstname. When you make a symlink to a directory:
ln -s this/really/deep/dir/struc/ture shortcut
and you change directory with 'cd shortcut', you end up in the directory this/really/deep/dir/struc/ture

Administrative oriented commands - like "ls" to see what files you have, or "rm" for removing files - will act on the symlink itself, of course: how else could you remove the symlink when you're done with it?

This was about permissions, so a word on that too. The permissions of a symlink are always rwxrwxrwx - you can't change those. To access the file/directory it's pointing to, the permissions of that file apply, without modifications. (it would be kind of pointless anyway, you could only restrict access by having permissions on the symlink).

Now, why are symlinks allowed for directories, while hard links weren't? After all, you can goof up with symlinks too. Issue the following commands:
ln -s subdir1 subdir2
ln -s subdir2 subdir1
cd subdir1
and the "cd" command sees that subdir1 is a symlink to subdir2, so it will try to cd to subdir2, but it sees subdir2 is a symlink to subdir1 and it will try to cd to subdir1, etc. The point here is, that it actually sees every time it follows a symlink, and Unix has put a cap on the number of times (IIRC, 20) it will do that in trying to find a file. With "hard links", you can't see when there's a hard link, as it really is nothing special.

This example also shows that symlinks may point to "nowhere" - as you see in the example, you can even make a symlink to a non-existent file - but a symlink also won't notice it when the file it points to no longer exists.

Finally, sometimes hard links don't work for files either, so you need to use symlinks. The reason is, that you can assemble your whole Unix filesystem tree from multiple disks (or partitions, or logical volumes). Compare with DOS/Windows: there, you can use multiple disks (or partitions) too. Under DOS, when you use a second disk/partition, you "format" it, and it becomes visible as disk D: (or another letter). The formatting here means, to initialize the administration on the disk.

The same principle applies to Unix. When using a new disk, you first have to initialize the administration on the disk - with the command 'mkfs' - which creates a root directory, sets up the administration of free blocks, etc. The second step is different: if you want to use the new disk, you have to mount it under a directory, and then the new disk becomes part of the one, big filesystem tree. So, when you have issued the command
mount /dev/sdb1 /home
it means, that the directory "/home" actually is the root directory on disk /dev/sdb1 (**), and the directory "/home/h3ll" is the subdirectory "h3ll" of the root directory on disk /dev/sdb1, and so on.

However, each disk has its own filesystem administration, and numbers its inodes from 1 onwards (***). We've seen that each directory entry consists of a filename and an inode number - but not some indication on which disk. So, you can make a hard link only within the same disk. You cannot make a hard link to a file somewhere under the /home directory from, say, the /tmp directory, in the above example. Then you'd need a symlink.

(**) /dev/sdb1 is the Linux name for the first partition on the second SATA/SCSI-disk.

(***) actually, inode 1 isn't used anymore - had a fixed meaning but that's been lost in the mists of time. The root directory of a filesystem always has inode 2.

Dan O.

20th July 2009, 09:42 AM

(Note: making "hard links" is not possible for directories. Unix relies on the fact that the directory structure is strictly a tree. If you could make a "hard link" for a directory, you could also make a loop in the directory structure, and you can see that all kinds of mischief could come from that.)

I used to do this back when UNIX was young. Relinking ".." to a secret directory was one of my favorites.

nathan

23rd July 2009, 04:25 AM

deleted

laca

23rd July 2009, 04:54 AM

The SUID, SGID and sticky bits are independent from this series of nine bits, and have separate meanings. SUID (set user ID) bit says that whenever a user executes this file (the permissions are favorable, and the user actually does sexecute) then during that execution the owner ID is set to the file's owner, not whoever he really is. This is generally used to allow a low level user to have high level permissions (like, say, root, which is the highest permission available) only while running this executable. Needless to say, this can be dangerous, and this only user at the higher level is allowed to turn on the SUID bit for an executable, and he should only do so for totally trusted executable files. SGID says the same thing for group permissions.

No, not only root can set the SUID/SGID bits. Only the owner of the file can set the SUID/SGID bits.