Saturday, January 29, 2011

su to myself without password

How can one set it up so that su to the same user that is currently logged in, that is

foo$ su -c 'something' foo

does not require a password? This wouldn't add or remove any security, as it should be a noop.

The reason for wanting this is that I would like to have a class of users "below" root that can administer some specific services on the machine that run under that user, e.g., news or mysql (inspect their data, change the configuration, restart, etc.). Those users would get sudo rights to that account, and that usually works well, except that the init scripts in some cases call

su -c 'start_daemon ...' daemonuser

and that brings down this scheme. Of course, I can change the init scripts or add additional sudo permissions, but I would like to avoid these sort of exceptions, because they are a mess to maintain in the long run.

The configuration for su is in PAM, so the right magic possibly lies there.

  • You should be using sudo for this, not su. With sudo, you can specify NOPASSWD in /etc/sudoers:

    username  ALL=/path/to/command  NOPASSWD: ALL
    
    Peter Eisentraut : I know that, but that was not the question.
    Nunya : Set sudo up with no password then use this command sudo su -
    From ErikA
  • I think there is a basic misunderstanding here.

    Those users would get sudo rights to that account, and that usually works well, except that the init scripts in some cases call su -c 'start_daemon ...' daemonuser and that brings down this scheme.

    When an init script does su -c <start_daemon> <daemon_user> what it is doing is switching the context that the daemon is running under.

    for example our tomcat scripts do exactly this so that the daemon can run with the "tomcat" user permissions.

    Now, if you go changing the init scripts to do su -c <start_daemon> <your_user> you WILL BREAK the daemon as it expects to be run under a certain enviroment.

    Giving your users sudo permission to those scripts, as everyone else has already said is the correct way to give them the ability to manage those daemons.

    Peter Eisentraut : I don't want to change the init script. I want someone who is logged in as, say, "tomcat", to be able to run the init script. But that will fail because `su -c tomcat` will ask for a password, even if you are already logged in as tomcat, and that will usually not exist anyway.
    Zypher : @Peter: Your init script should have an if statment like: `if ["$USERNAME" = 'tomcat'] then tomcat` to take care of this situation. If that doesn't exist, well you might just have to change the init script
    From Zypher
  • You may be able to do this by editing su's PAM file in /etc/pam.d and using the pam_succeed_if module. The file already has an entry for root, so copy that line and add another one after it.

    account sufficient pam_succeed_if.so uid = 0 use_uid quiet
    account sufficient pam_succeed_if.so uid = [your UID here] use_uid quiet

    Peter Eisentraut : That's kind of a promising direction, but I think I would conceptually need something like `pam_succeed_if.so uid = user`.
  • Run visudo and add this line:

    yourusername ALL=(ALL) NOPASSWD: /bin/su - yourusername

    and add this to the beginning of the init script:

    alias su='sudo su'

    Peter Eisentraut : I don't want to change the script. If I could, I would just take out the `su` call or something.
  • "Giving your users sudo permission to those scripts, as everyone else has already said is the correct way to give them the ability to manage those daemons." - Zypher

    That's what I'd do. He's saying you should let the users run the scripts (and only the scripts) as root by editing your sudoers file. Since root can su anywhere with no password, the scripts should run fine. I'm doing precisely this now, actually.

    Keep in mind that the initscripts are intended to run as root, that's why the su is there in the first place (to drop root privileges).

    Peter Eisentraut : Yeah, that's what I've been doing, but I was looking for something better.

0 comments:

Post a Comment