Weblog entry #1 for dalitec
See all weblog entries made by dalitec.
#1
sudo as another user does not work
Posted by dalitec on Sat 22 Dec 2012 at 12:52
Using sudo as another user using the -U option still asks for my password and not the other user password. What is the correct command. example I am user a and i want sudo as user b. when I do sudo -U userb command i am asked for password for user a and not user b. Thanks for help
Comments on this Entry
Thanks for the reply.So if I want apache user to run a command as userb,I need to supply userb's password in the shell command?
[ Parent | Reply to this comment ]
Posted by Anonymous (84.45.xx.xx) on Mon 24 Dec 2012 at 05:01
No, "sudo" (by default) asks the requesting users password. You can configure it otherwise (see targetpw in sudoers).
However if you want to run a command as another user, and know their password you can use the "su" command instead (see -c option), so I'm not sure why anyone would use the "sudo" command with targetpw option set in sudoers for the situation you describe as it is overcomplicated (usually a bad idea where security is concerned).
The Apache user in Debian (www-data) probably shouldn't have a knowable password.
More common patterns with the Apache user are to run setuid executables (so a web page can access something which requires elevated privileges), or to create a database or filesystem entry with the Apache user and have a privileged user check that routinely (cron), or using a tool like incron, to take action on that request. The later approach is probably safer, since setuid scripts are notoriously hard to secure properly.
However if you want to run a command as another user, and know their password you can use the "su" command instead (see -c option), so I'm not sure why anyone would use the "sudo" command with targetpw option set in sudoers for the situation you describe as it is overcomplicated (usually a bad idea where security is concerned).
The Apache user in Debian (www-data) probably shouldn't have a knowable password.
More common patterns with the Apache user are to run setuid executables (so a web page can access something which requires elevated privileges), or to create a database or filesystem entry with the Apache user and have a privileged user check that routinely (cron), or using a tool like incron, to take action on that request. The later approach is probably safer, since setuid scripts are notoriously hard to secure properly.
[ Parent | Reply to this comment ]
Thanks
May be I am over complicating myself. All I basically want to do is upon a user clickin a button create a directory somedir and move that somedir directory to apache docroot directory which is owned by root. Since I already have a shellscipt called that successfully creates the directory, should I use incron to move that somedir directory to apache docroot ?
May be I am over complicating myself. All I basically want to do is upon a user clickin a button create a directory somedir and move that somedir directory to apache docroot directory which is owned by root. Since I already have a shellscipt called that successfully creates the directory, should I use incron to move that somedir directory to apache docroot ?
[ Parent | Reply to this comment ]
Wouldn't it be more consistent if Apache's docroot was owned by Apache's user (i.e. www-data)?
[ Parent | Reply to this comment ]
I thought about doing that, but wasn't sure, if it would be secure enough that other than the system creating directories only in the immediate docroot directory. I will try that for now while investigating any security threat that may be a possibility. Thanks.
[ Parent | Reply to this comment ]
The main difference between
sudo and su, apart from whose password is asked, is that the former allows a fine-grained definition of who is allowed to do what. In your case, you could instruct it to allow one user (www-data) to execute exactly one command (your script) as another user (the docroot owner) without asking any password at all:
www-data ALL = (docroot-owner) NOPASSWD: /path/to/script
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]