Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

What does GID actually mean?

I have Googled it and this is what linux.about.com said:

Group identification number for the process. Valid group numbers are given in /etc/group,
and in the GID field of /etc/passwd file. When a process is started, its GID is set to the
GID of its parent process.
  • But what does that mean?

The permissions I have for my folder is currently at 0755

I understand if I set the UID for the Owner it will be 4755

And if I set the GID of the Group it will be 2755

If I set the Sticky Bit for Others it will be 1755

  • Is it even important to set those permissions?
share|improve this question

3 Answers 3

up vote 8 down vote accepted

Every process in a UNIX-like system, just like every file, has an owner (the user, either real or a system "pseudo-user", such as daemon, bin, man, etc) and a group owner. The group owner for a user's files is typically that user's primary group, and in a similar fashion, any processes you start are typically owned by your user ID and by your primary group ID.

Sometimes, though, it is necessary to have elevated privileges to run certain commands, but it is not desirable to give full administrative rights. For example, the passwd command needs access to the system's shadow password file, so that it can update your password. Obviously, you don't want to give every user root privileges, just so they can reset their password - that would undoubtedly lead to chaos! Instead, there needs to be another way to temporarily grant elevated privileges to users to perform certain tasks. That is what the SETUID and SETGID bits are for. It is a way to tell the kernel to temporarily raise the user's privileges, for the duration of the marked command's execution. A SETUID binary will be executed with the privileges of the owner of the executable file (usually root), and a SETGID binary will be executed with the group privileges of the group owner of the executable file. In the case of the passwd command, which belongs to root and is SETUID, it allows normal users to directly affect the contents of the password file, in a controlled and predictable manner, by executing with root privileges. There are numerous other SETUID commands on UNIX-like systems (chsh, screen, ping, su, etc), all of which require elevated privileges to operate correctly. There are also a few SETGID programs, where the kernel temporarily changes the GID of the process, to allow access to logfiles, etc. sendmail is such a utility.

The sticky bit serves a slightly different purpose. Its most common use is to ensure that only the user account that created a file may delete it. Think about the /tmp directory. It has very liberal permissions, which allow anyone to create files there. This is good, and allows users' processes to create temporary files (screen, ssh, etc, keep state information in /tmp). To protect a user's temp files, /tmp has the sticky bit set, so that only I can delete my files, and only you can delete yours. Of course, root can do anything, but we have to hope that the sysadmin isn't deranged!

For normal files (that is, for non-executable files), there is little point in setting the SETUID/SETGID bits. SETGID on directories on some systems controls the default group owner for new files created in that directory.

share|improve this answer
    
Ah awesome, thanks for that. So therefore, the Sticky Bit is like a personal (user) permission? That answer was well worded and understandable. –  Kevdog777 Jul 23 '12 at 11:01
1  
Thank you! The sticky bit provides a little protection for files in a directory with liberal permissions. It's not really specific to a given user, as the same level of protection is afforded to all files, no matter who the owner is. It's a way to allow anyone to create files, and to ensure only the owner can destroy them. –  D_Bye Jul 23 '12 at 11:11
    
+1, D_bye, could you please share an example for setgid bit set on directory. Thanks –  Ankit May 10 '13 at 14:14
1  
@Ankit Under Solaris (and almost certainly others - I only use *BSD and Solaris, though), if the setgid bit is set on a directory, any new files created under that directory will have the same group owner as the directory itself, and will not inherit the primary group of (the user running) the creating process. –  D_Bye May 20 '13 at 13:08

The GID is, as you have found, the ID number of a group. It is simply a convinient way for the OS to express the (user) group associated with something (a process, a file, etc.); instead of a potentially long string identifier, it can be expressed as a fixed size number.

In a file permissions value of four octal digits (for example, 0755), the third digit specifies the group's permissions to the file. If you omit the first digit, it's the second digit that specifies the group's permissions. Note that files and directories are treated the same in this regard, but that the exact meaning of each permissions bit is somewhat non-intuitive in the case of directories.

The two concepts are related, but serve very different purposes.

As for your question "is it even important to set those permissions?"; they are always set to something, but since in most cases the initial digit is 0 ("nothing special"), it tends to be omitted for brevity. Whether you need to specify some other value depends entirely on the usage pattern for the file or directory in question.

share|improve this answer

I think you mean the "SGID" bit of a file, which is not the same as its GID.

Here's a typical file on my computer (output of ls -l):

-rw-r----- 1 bristol    users 16 2012-07-23 11:36 file.txt
abbbcccddd <-- See explanation below.

If you look at the first 10 symbols,

(a) - : This is just a plain old file (as opposed to a directory, symlink, pipe etc. ...)

(b) rw- : The owner can read and write this file, but not execute it. The owner is "bristol" as you can see later in the line.

(c) r-- : Members of the group this file belongs to ("users" in the example) other than the owner can read, but not write or execute this file.

(d) --- : Anyone else can't access this file at all (except root of course).

The GID field is the one that tells you which group this file belongs to - in this case "users".

The field you probably meant, based on your description, is the SGID bit, and here's a better explanation than I could come up with:

http://www.codecoffee.com/tipsforlinux/articles/028.html

The short version is: if an executable file has the SGID bit set, then anyone who's not in the group but can execute this file temporarily gains the rights of this group while the program is executing.

For example, if you have a group "spool" that can read and write files in the print spooler directory, you don't want just anyone to mess with this directory but you do want them to be able to print files, you can make some printing program or script have group "spool" and set the SGID bit and when anyone launches this program, the program can now write to the spooler directory without the person running it gaining full access.

share|improve this answer
    
That is good, thank you for that. I do understand the permissions part, (the abbbcccddd part) - but thatnk you :) –  Kevdog777 Jul 23 '12 at 10:56
    
I have just seen my permissions on the tmp folder is drwxrwxrwt .... 2 sys .... sys .... 1024 Jul 24 15:17 tmp. What does the abbbcccddt (letter 't') mean? - I understand that "d=directory", "rwx=read, write, execute"; but I have never seen the 't' at the end before. Is that special permission for the tmp folder? –  Kevdog777 Jul 24 '12 at 15:31
    
Small t is "executable (x) and sticky bit set". See above for an explanation of why this is usual on /tmp. –  Bristol Jul 25 '12 at 10:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.