Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: bakedjake
When implementing scripts on *nix hosts the question that invariably comes up is how the numerical designation often given in instructions matches permissions. i.e some script instructions will say chmod such and such a file to 755, but how does that relate to the read write execute designations more commonly seen when using an FTP client for example?
The permission structure is not related to telnet or FTP but Unix. The structure of "Owner, Group, World" and "User, Group, Other" are interchangeable, they mean the same thing.
On Unix systems when a user account is created it is assigned it's own unique identifier. When that user creates a file or a directory, Unix attaches the unique identifier of the account that created it, he/she is then identified as the "Owner" or "User" of that file or directory and resources (i.e. programs, scripts, etc.).
Unix also allows you to have users belong to a "Group". In simple terms, this is done by assigning multiple accounts, or users to the same group. The reason for this is to allow users to share common access rights to files, and 'resources', that belong to the same group as this "group" of users, this is all based on the resource's permissions for "Group".
Users who are neither the "Owner/User" or within the "Group" are treated as "World/Other".
So that defines who everyone is in relation to files, directories, pograms, etc, but what are they allowed to do with these files, and programs?
That's where permissions come in. For each resource you define what they are allowed to do to the resource you are changing permissions on. The possibilities are
"rwx" (r)ead, (w)rite, e(x)ecute, for Owner/User,
"rwx" for Group,
"rwx" for World/Other
The permissions are actually specified in binary, so each position for "rwx" can be "on" or "off". If you want the Owner/User to be able to (r)ead, (w)rite, and e(x)ecute this file, you would turn all bits to "on" or 111, the thing to remember is that this is binary 111 not the decimal number 111. Repeat this for "Group" and you have three more digits to repesent "rwx", do it again for "World/Other" and you have three more binary digits to represent "rwx". This gives three sets of three binary "digits (a misnomer in this case)", and converting these binary sets, gives a three digit decimal number.
As we all know in the decimal number system each position has a significance based on the position it holds relative to the base. So we recognize that in the decimal number 1059, the 9 occupies the "ones" position, the 5 occupies the "tens", the 0 occupies the "hundreds", and the 1 occuppies the thousands. This tells us that the 1 in 1059 is actually 1000, and and the 0 is a placeholder for hundreds, the 5 is actually 50, and the 9 is 9. We don't think about it this way normally but it really stands for 1000+0+50+9 = 1059.
The positions of significance are arrived at by raising the base to the power of 0 thru infinity.
10^0 = ones
10^1 = tens
10^2 = hundreds
10^3 = thousands
The same is true for binary, but since we are dealing with a base 2 numbering system each position of significance can be represented by just two digits, a "0" or a "1" instead of the ten digits (0-9) available in decimal numbers.
2^0 = ones
2^1 = twos
2^2 = fours
2^3 = eights
Counting in binary then, the number 101 represents the number 5, the 1 occupies the "ones" position, the 0 occupies the "twos" position, and the 1 occupies the "fours" position. This tells us that the 1 is actually a 1, the 0 is a placeholder for the "twos", the 1 is actually a 4. So it really stands for 1+0+4=5
Let's go back to the permissions now. So rwx are represented by a 1 or a 0. A 1 when it is allowed and a 0 when it is not.
So we want to give:
"Owner/User" rwx permissions
anyone in the same "Group" r-x (note the dash, to maintain numerical significance)
And everyone else (Wold/Other) read and execute r-x
Assigning the on off bits to correspond to rwx would give:
"Owner/User" 111 (rwx)
"Group" 101 (r-x)
Let's do the math:
111 = 4+2+1 = 7
101 = 4+0+1 = 5
101 = 4+0+1 = 5
FTP clients usually structure the check boxes for each of these the same way, you check it and it is "on" (binary 1), you uncheck or leave it blank it is "off" (binary 0) and there are three sets of three to cover all possibilities of permissions.
Add the numbers generated above to the following:
1000 sticky bit
Set user changes the effective UID to the owner of the file.
Set group changes the effective GID to the owner of the file.
Sticky bit used on a directory allows users to write files in that directory. an example of a sticky bit directory would be /tmp
By default, if you own the directory or have the proper permissions, you have the authority to remove files from it. This is done at the directory level instead of the file level because when you create or remove a file, you are adding or removing an entry in the directory (think of it as altering the contents of the directory).
This creates a problem with scratch areas that all users can toss files in, such as /tmp. User "joe" could put a file in /tmp and user "jane" could delete it (because jane has rwx access to the directory).
The sticky-bit on directories forces the behavior that (within that directory with the sticky-bit set) only the owner of the file can remove the file. The same applies to directories within that directory that has the sticky-bit set. To continue the above example, joe could also create a directory in /tmp that jane couldn't remove.
The "Set User", "Set Group", sticky-bit bits are tied to the execute bit. When you're looking for them, look at the three places where you expect to see a `x'. SUID/SGID bits change the `x' to a `s'. Sticky-bits change the last `x' to a `t'. All of these bits do different things, depending on whether you set them on files or dirs. To add complication to the issue, some flavors of UNIX behave differently than others in this area, particularly with directories and SUID/SGID bits set. To stir up the pot even more, SUID/SGID/sticky-bit settings behave differently depending on if the relevant "Execute" ("x") bit is set or not.
We'll only talk about SUID/GID/sticky-bit settings as they are with the execute bit set, and only in their most common usage (SUID/SGID with files, sticky-bit on dirs).
"man ls" will generally tell you how your UNIX-like OS handles this mess (or refer you to another manpage that will).
Yes, yet another reference to those silly manpages :)
On the note of number counting, Air made the excellent connection that you merely count bits. These happen to be "Octal" numbers, meaning "0-7" (Get it? "octal", as-in "only eight"?) It isn't a coincidence that there are three bits to make one octal "digit", either, (2)3 (or 2*2*2) is 8.
SUID/SGID/sticky-bits are counted in similiar manner as the rwx bits, but as an add-on. You count 4-2-1 just like above, but this time we're talking only about the "new" bit and you're defining "where to place it". 4 means "user", 2 means "group", and 1 means "other" (left-to-right, just like the rwx sequence).
So, to use one of these "new" bits with the chmod(1) command, you could do "u+s" to set the SUID bit on "user". You could also add it to the numeric by making it the fourth number, adding it to the left side. For example, "chmod 4755 foo" is fairly common practace (meaning, SUID, rwx for owner, r-x for group and other). Sometimes you'll see a "chmod 0644" or similiar with a leading `0'. That is a way to tell chmod(1) to clear any SUID/SGID/sticky-bits. It is generally good practice to toss in a leading `0' when using chmod(1) with numbers when you aren't explicitly setting the SUID/SGID/sticky-bit.
Oh, and lastly, the infamous /tmp. You set the sticky-bit on it a-la "chmod 1777 /tmp" or "chmod a+rwx,u+t /tmp". Solaris requires that you "u+t", BSD allows you to use "g+t" but not "o+t", dunno what linux does. man chmod for specifics. You'll find that most folks don't deal with "chmod ...+t" when setting the sticky-bit, they'll just "1777" it instead (since the only time you set it is with a+rwx dirs).
When I think about SUID/SGID/sticky-bits, I think of *all* of them as "sticky bits" and we're merely determining where to place it. Placement, of course, defines its behavior. Technically, this is not the correct terminology, but it sure makes things easier to remember.