1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

clarification on setuid

Discussion in 'General' started by magnesium, May 8, 2012.

  1. magnesium

    magnesium New Member

    Messages:
    4
    Thanks Received:
    0
    From reading the FreeBSD documentation, it seems like the setuid permission is given to a script or a program and allows it to run as another UID. The reason behind this, using the passwd command as an example, is to allow a non-root user to change their password without changing anyone else's password (passwd prevents one user from being able to change other user's passords). Is this correct? Is the setuid permission used for any other purpose than to allow a user to use a program to access a file as another user?

    A follow on question (if the above is incorrect, ignore this question), would implementing finer-grained file permissions (different permissions for different portions of a file) remove the necessity for the setuid permission? For example, in the password database, each user would have permission to edit their own password, but not any other user's password. This way, passwd could run with the permissions of the user that's changing their password. I realize that this would be a huge rewrite, but beyond that, is this a possible solution, or would it just create more problems than it would solve?
     
  2. SirDice

    SirDice Moderator Staff Member Moderator

    Messages:
    17,521
    Thanks Received:
    2,351
    It's a possible solution, unfortunately you can't give different permissions on different parts of a file. It's an all or nothing deal, permissions are set on the entire file. It would be an administrative disaster if parts of a file could have different permissions.
     
  3. fluca1978

    fluca1978 New Member

    Messages:
    733
    Thanks Received:
    68
    It will introduce a lot of problems. If I get it right you should have to create a password database owned by, let's say, a pwd_daemon user. The passwd(1) program will then check the current uid and modify only such row. Up to here it is not that big deal, but the passwd(1) program has to be able to write the file in any part, and therefore must run with a suid set to pwd_daemon. On the other hand, you would have to install a lot of per-user specific programs and/or configuration files that gives each user the capability to modify only their data....system mess!
    Moreover, remember that passwd(1) is an example, but other services could require suid even when not dealing with files.
     
  4. magnesium

    magnesium New Member

    Messages:
    4
    Thanks Received:
    0
    The kernel and all setuid programs would obviously need to be modified to work with this method. Also, it would obviously take some getting use to. Assuming the interfaces (text editors, etc) are setup to clearly display the permissions for each part of files, could you explain how it would be an administrative disaster?

    For a given user, why does passwd(1) have to be able to edit any part of the password file? If userA ran it, it would be able to edit userA's password only, then if userB ran it, it would be able to edit userB's password only.

    I don't think you'd have to install any more programs and/or configuration files, just have to modify them to work with this new method. Could you explain more why you think user specific programs/configuration files would be needed?

    Could you give an example of when a program/script would need setuid permissions other than to edit files?
     
  5. SirDice

    SirDice Moderator Staff Member Moderator

    Messages:
    17,521
    Thanks Received:
    2,351
    Because people are already creating one big mess with just an ACL on the file. Imagine what happens when that file has multiple parts, each with their own ACL.

    And how is a service desk going to reset a user's password if it can't access it?

    Code:
    dice@molly:~> ll /sbin/ping
    -r-sr-xr-x  1 root  wheel  28016 Apr 22 18:27 /sbin/ping
    


    Your mission, if you choose to accept it, is to find out why ping(8) needs suid :e
     
  6. Uniballer

    Uniballer Member

    Messages:
    251
    Thanks Received:
    26
    One implementation problem is that the current /etc/passwd file format uses a variable amount of data for each entry. This is a problem because the size of each entry could change, and the permissions/ownership of that entry's range would have to change with it. Ugly mess.
     
  7. anon12b

    anon12b New Member

    Messages:
    17
    Thanks Received:
    5
    Openwall TCB is an implementation of SGID-only passwd(1). You need the group to access /etc/tcb, but your actual password is writable by you. It stops the user randomly editing the file, and limits any flaws in passwd(1) to letting you mess with your password. They have the same concept for their crontabs.
     
  8. magnesium

    magnesium New Member

    Messages:
    4
    Thanks Received:
    0
    I didn't realize setting permissions was such a big problem. So it's a matter of this method exasperating an existing problem, not that this method creates a new problems, correct?
    One way would be to create a group for the service desk and give that group edit privileges over the appropriate users' password.
    I think I will accept this mission, although I may regret this decision :)

    This would have to be solved, but I don't think it'd be a road block, just a speed bump (maybe a large one).

    Originally, I was thinking to also eliminate setgid as well. If both setuid and setgid were eliminated, then a user would be able to randomly edit the their password, including setting invalid values. This would be a downside to this method, but it may be worth it, or not.