Find the answer to your Linux question:
Results 1 to 4 of 4
I'd like to discuss the uses and adavantages of SUID, GUID, and the sticky bit. I've just read that if SUID and GUID permissions are set, then the file is ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319

    SUID, GUID, Sticky Bit


    I'd like to discuss the uses and adavantages of SUID, GUID, and the sticky bit. I've just read that if SUID and GUID permissions are set, then the file is always run as the owner or the group respectively when the file is run by anyone. How does this effect security? Why is this dangerous? If the file can't be modified, then isn't it safe for it to run by any user? Furtheremore, what is the use of GUID? When is it an appropriate time to use this?

    I've gotten two definitions on sticky bits. First definition states
    Setting the sticky bit tells Unix that once the concerned application is executed, it remains in memory.
    The second defintions states
    Sticky bit allows a user to delete the file that ONLY the user owns and non other within a directory. The sticky bit can only be set by the root user.
    After reading both of these definitions, I'm thinking that the latter one is more appropriate since /tmp has the sticky bit set. Obviously only the user can delete files or directories created there(other than root user). Any thoughts on these inquiries is greatly appreciated.
    The best things in life are free.

  2. #2
    Linux Engineer
    Join Date
    Jan 2003
    Location
    Lebanon, pa
    Posts
    994
    Say the owner of a file is root and it were to have an exploitable buffer overflow or something, then anyone running that file could gain root privilages or be able to run a command with root privilages which would compromise the system. As for GUID, say a program has to write to a directory owned by root/users and you don't want to run the program as root. Well if the program doesn't run as in the users group, it won't have access to the directory to write to it. Ok now on the sticky bits, both are correctly. It depends on how its used. When set on a directory, only root, file owner, or directory owner can remove files. When set on a file, its tells it to remain in memory. That was used on older version of unix. With linux's virtual memory management, you don't need to use that.

  3. #3
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319

    SUID

    OK,

    Let's say I have a file called run.exe. This is nothing but an executable that will print "Hello World" to the screen. If this file is owned by the root user and I set SUID permissions on this file, I'm assuming that anyone can run this file and that it will be run as the root user. Once the file runs and prints, I don't see how this could he harmful. Can you give me a better example of this?
    Does it matter that the s in the permission filed is lowercase or capitalized? In my debian workstation, if I use chmod with 4000, it becomes lower case but if I use chmod with u+s, then it gets capitalized. On my FreeBSD account, they both result in capitalized 'S'.
    The best things in life are free.

  4. #4
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    You're run.exe probably won't compromize the system since it has no user or file system interaction. However, say that you're setting root SUID on GAIM. Then, first a user could overwrite system config files, since he/she could save incoming files to say /etc/rc.d/rc.sysinit, which is obviously bad. Secondly, it's very possible that GAIM is not bug-free. Many bugs (like buffer overflows) can be used to gain privileges, and if the process in question runs as root, the risk obviously involves the entire system, which is also bad. That's also a good reason why you shouldn't log in as root.

    SUID, SGID and sticky bits affect files and directories differently. SUID has no effect on directories, SGID on a directory makes all files created in that directory to have the same GID as the directory itself. The sticky bit on a directory allows the user that owns a file in that directory to delete the file without having write access to the directory itself. The sticky bit on a file has no real effect on modern UNIXes, like genlee said. You can set it on eg. /bin/ls to make it stay on the swap device after it has been run. It probably has no effect at all, but say if your swap device is a 25000 RPM Ultra-Super-320 Bit-Next Generation SCSI, it could probably load some microseconds faster than from your root filesystem (which is on a 5400 RPM PIO IDE bus, of course) if it would have been removed from your RAM (which it most probably won't be).

    Also, concerning the SUID and SGID bits, consider what people have done to games. They are usually chown'ed to the "games" group, so that they can write the high score files without having to be root. It has even better effects on programs such as utempter and write, since you really don't want them to switch UID.

Posting Permissions

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