Is this possible with sudo !!!

[Whitehorse_1]

Admins. please bear with this freaky qn...

Is it possible for a normal user to run WITHOUT password the below command, who got limited sudo permission,

sudo su - root -c <script>

I know, instead we can just give the script in sudo for that user, to have root priviledge.. WH

[Dennis Handly]

Allowing sudo to do su to root would bypass all logging. You should just allow it to do that script.

[A. Clay Stephenson]

Well, if sudo were setup with this command AND /etc/sudoers allowed this user to execute su as root AND this same regular user had previously executed some sort of sudo'ed command within the timestamp_timeout period specified in the sudoers file then this invocation of sudo would not trigger a password requirement. Note that the first invocation of sudo by the user would require a password and that would create a timestamp file. Any command entered by the same user before the password timeout would not require a password.

Now this is exactly the kind of command that you do not want sudo to do. Let sudo execute this command directly and set the effective UID.

It would probably lead to a more straightforward solution if you explained what you are trying to do rather than asking if this Plan A, Plan B, or Plan C will work.

[Geoff Wild]

No - they still need to enter their password.

Rgds...Geoff

[skt_skt]

entry in /etc/sudoers
username ALL=(ALL) NOPASSWD: ALL

Both of the below commands work.
sudo su -
sudo su - root

$ sudo su - root -c /home/kumarts/ebrdo0pb_dgfiles
You have mail.
sh: /home/kumarts/ebrdo0pb_dgfiles: not found.
logout

[Bill Hassell]

> username ALL=(ALL) NOPASSWD: ALL

Yes, the user can do *ANYTHING* without any additional password. So you might as well remove the password for root because there is absolutely no security now. The above construct has given keys away and your system may need a complete reinstall in a few minutes.

sudo's design is to LIMIT the root capabilities, by command, even down to the parameters allowed for a command. ALL=(ALL) just disables all those capabilities.

[skt_skt]

Just to remind that the user which i listed is an administrator user who can do all operation without the root password.

[dirk dierickx]

you probably do not want to do this, or at least not in the way you described.

better is to find another (saner) solution to your problem.

[G V R Shankar]

You can try the following

/usr/sbin/visudo

Under Cmnd alias specification

Cmnd_Alias ABCD=<script path>

Under User privilege specification

Username NOPASSWD: ABCD

If the user is already present in sudoers file, add (NOPASSWD: ABCD) at the end of the line.
Now run the scipt as

sudo <script path>

Please remove write permission for the user on the script. He shud have only read and execute. If he is given write permission on the script, he can modify the script for his needs.
This shud work, without a password and with violating security issues.

Ravi.

[Ralph Grothe]

It cannot be stressed enough what Bill wrote.
I think this madness derives from settings in certain Live Linux or Ubuntu distros?

[Matti_Kurkela]

The optimum way to fulfill the original requirement would be something like this line in the sudoers file:

user host = (root) NOPASSWD: /usr/bin/su - root -c <script>

This will allow the user to run only this one script as root without asking for a password.
The user must then run the script _using exactly that specified command line_. The "<script>" should be specified as a full path, and the user must then always write it exactly the same way.

If you're sure you won't *ever* copy this sudoers file to other hosts without carefully inspecting it first, you can replace the "host" part with "ALL".

Note that you must always use a full path when identifying the commands the user may execute (i.e. "/usr/bin/su" instead of just "su"). If you don't use a full path, visudo will not accept it, because the user would be able to exploit the definition easily by changing his PATH setting.

Because visudo cannot verify the command arguments, it cannot force you to use a full path in "<script>". To keep your system secure, you must use a full path in this too.

As others have noted, the script (and the directory the script is located in) *must not* be writeable by the user.

Furthermore, if the script uses command line parameters or other user-supplied data, the script must be written *very very carefully*: if the script contains even a single unquoted parameter or variable expansion (like $1 or $something), the user might be able to gain unrestricted root by using strategically-placed semicolons in the parameters or other input.

MK