chmod u+s


Results 1 to 4 of 4

Thread: chmod u+s

Hybrid View

  1. #1
    Join Date
    Aug 2002
    Location
    43400
    Posts
    824

    chmod u+s

    Hi

    What does the s mean?

    Thanx.
    Isn't it strange the onset of overheating will result in freezing?

  2. #2
    Join Date
    Mar 2003
    Location
    Hampton, VA
    Posts
    714
    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

  3. #3
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,936
    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.

  4. #4
    Join Date
    Jan 2024
    Posts
    1

    Thumbs up Great explanation

    Quote Originally Posted by bwkaz View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •