Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
For clarification, the calls to "su" are in some script that I don't want to change. If I would want to change it, this would be trivial. So any answer that proposes to change the su call to sudo or something else is incorrect. The goal is to make the existing su call succeed without requiring a password. –  Peter Eisentraut Jan 13 '10 at 18:25
add comment

5 Answers

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
share|improve this answer
    
I know that, but that was not the question. –  Peter Eisentraut Jan 8 '10 at 15:36
    
Set sudo up with no password then use this command sudo su - <username> –  Nunya Jan 8 '10 at 18:26
add comment

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.

share|improve this answer
    
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 <start_daemon> tomcat will ask for a password, even if you are already logged in as tomcat, and that will usually not exist anyway. –  Peter Eisentraut Jan 13 '10 at 18:29
3  
@Peter: Your init script should have an if statment like: if ["$USERNAME" = 'tomcat'] then <run script else su -c <start_daemon> tomcat to take care of this situation. If that doesn't exist, well you might just have to change the init script –  Zypher Jan 13 '10 at 19:52
add comment

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

share|improve this answer
    
That's kind of a promising direction, but I think I would conceptually need something like pam_succeed_if.so uid = user. –  Peter Eisentraut Jan 13 '10 at 19:10
add comment

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'

share|improve this answer
    
I don't want to change the script. If I could, I would just take out the su call or something. –  Peter Eisentraut Jan 13 '10 at 18:30
add comment

"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).

share|improve this answer
    
Yeah, that's what I've been doing, but I was looking for something better. –  Peter Eisentraut Jan 13 '10 at 22:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.