chmod u+s

[dysharmonic]

Hi

What does the s mean?

Thanx.

[evac-q8r]

It is in the man pages for chmod. I will let you access them and make your own inferences about this option because I cannot seem to understand what its particular use is.

EVAC

[bwkaz]

set-user-id or set-group-id

If the s group of permissions has the user bit set (corresponding to u+s), then whenever anyone executes that program, the process takes on the privileges of whoever owns it. If root owns a file that's marked u+s and o+x (everyone can execute it), then the file is called "suid root" -- whenever anyone runs it, the program gets full root privileges. This can be a security hole if improper care is given to securing the program itself.

The most widely-used reason for doing this is probably the su binary. In order to become another user, the process that's running needs to have root privileges (according to the manpage in section 2 for setuid, that is). So normal users can't run a program that changes the current UID -- this means that normally, no one would be able to use su except for root, which is obviously not good.

So you make root own the /bin/su program, and make it world executable (or in my case, group executable and then add only users that I wish to be able to become root to the appropriate group), so that when a user starts it up, it begins life with root's privileges. It can then switch UID's to anything it wants, subject to the program checking passwords.

Use of the g+s bit is similar -- but here, you're giving whoever can execute the program privileges of a certain group. I don't think I've ever seen this actually used, except for on directories. If that bit is set on a directory, then whichever group owns the directory will also own any files created inside that directory -- but this is a special extension that not all filesystems have to honor. The vast majority do (and I believe that POSIX also prescribes this, but I'm not sure), though.

[Cretoria]

set-user-id or set-group-id

If the s group of permissions has the user bit set (corresponding to u+s), then whenever anyone executes that program, the process takes on the privileges of whoever owns it. If root owns a file that's marked u+s and o+x (everyone can execute it), then the file is called "suid root" -- whenever anyone runs it, the program gets full root privileges. This can be a security hole if improper care is given to securing the program itself.

The most widely-used reason for doing this is probably the su binary. In order to become another user, the process that's running needs to have root privileges (according to the manpage in section 2 for setuid, that is). So normal users can't run a program that changes the current UID -- this means that normally, no one would be able to use su except for root, which is obviously not good.

So you make root own the /bin/su program, and make it world executable (or in my case, group executable and then add only users that I wish to be able to become root to the appropriate group), so that when a user starts it up, it begins life with root's privileges. It can then switch UID's to anything it wants, subject to the program checking passwords.

Use of the g+s bit is similar -- but here, you're giving whoever can execute the program privileges of a certain group. I don't think I've ever seen this actually used, except for on directories. If that bit is set on a directory, then whichever group owns the directory will also own any files created inside that directory -- but this is a special extension that not all filesystems have to honor. The vast majority do (and I believe that POSIX also prescribes this, but I'm not sure), though.

Thank you, this was clearly explained and it helped understand faster.

[james3]

When the setuid bit is set on an executable file, it allows a user who runs the file to temporarily gain the privileges of the file's owner.
For example, if an executable file owned by the root user has the setuid bit set, and a regular user runs this file, the executable will run with root privileges temporarily.