I use mint install application a lot but don't think it is safe if I allow the normal user I use to have full privileges over it. I was wondering if there is a way to gain access to this application only when root password is entered. Basically be able to use something like the admin password prompt of windows when installing a new application in terminal. I know I can log into root with su but I know that's definitely not safe. Any Ideas?

Edit: Again, I don't want to give privileges to the normal user using sudo or chmod or anything else.

  • As I said earlier, I don't want to give privileges to the normal user. – Jecht Tyre Aug 12 '14 at 17:31
  • Can you create a new user specifically (password protected) for that program and change the ownership of that program to that specific user? So with you only having the password, no one else can access it. – ryekayo Aug 12 '14 at 17:49
  • 2
    @JechtTyre you can use su -c 'command_to_run' if that's what you want. – Valentin Bajrami Aug 12 '14 at 18:36
  • 1
    Logging into root with su is perfectly fine, you just shouldn't live your whole life in there. If you want to make a command only executable by root, go for it – Michael Mrozek Aug 12 '14 at 20:11
  • 1
    I think the closest the Unix desktop systems have to Windows UAC is pkexec name-of-program. By default, it'll prompt for the root password every time it's run. – Mark Plotnick Aug 12 '14 at 21:44

If you need to do something that requires root privileges, you need to use some method of gaining root privileges, which on most modern systems means su, sudo, or a wrapper around one of these. What's dangerous about running commands as root (whether it's with su or sudo) is that it gives you a lot more ways to damage your system. So you should only run a command as root when the command actually requires it.

The main difference between su and sudo in their typical configuration is that for sudo, you type the same password as when you log in, whereas su requires a different password (the password of the root user). For a typical single-user machine, there isn't a significant difference between the two in terms of security. It's also possible to configure sudo not to require a password.

If you're working in a terminal and you want to run a command as root, with su, run:

su -c 'somecommand an_argument another_argument'

With sudo:

sudo somecommand an_argument another_argument

Either way, you'll be prompted for a password (the root password for su, your own password for sudo). Sudo can remember your password and not ask you again for the next few minutes; with su, you'll have to type it again each time.

You can also get a graphical prompt to type your password (with gksu, kdesu, …), but if you're already working in a terminal, that's less convenient.

  • This does not work with applications that need a shell. gives TTY error. e.g. su -c 'vim hello.txt' – Jecht Tyre Aug 13 '14 at 16:24
  • @JechtTyre You mentioned working in a terminal in your question, in which case su -c 'vim hello.txt' would work (but sudoedit can be more convenient and more secure). If you're not already in a terminal, then you can use gksu or kdesu or the like to get a GUI prompt. – Gilles Aug 13 '14 at 18:07

While keeping in mind that there are no free meals, it's possible to minimize risk.

If you'd like to run your script as root and immediately exit without password prompt and exit command then you'll have to compromise a bit.

The following solution lets you store your encrypted twice (or more) root password anywhere with the current user permissions.

High level:

  1. Encrypting root password in base64 twice once and placing the file anywhere (can be 1234.txt, for example).

  2. Invoking expect script with argument (the string from above decoded)

  3. Expect runs the desired script and exits.

  4. Cleanup file under /root invoked from expect and deletes bash_history (of common user) lines containing root, password encrypted file, and base64. To remove any trace the script was invoked (from common user perspective). This script is only accessible by root user.

So over all, it seems that from the common users' perspective, this script was never run, and it doesn't contain any sensitive password.

Furthermore, double base64 encryption, seems pretty random to innocent to me (though I'm not security expert, I would not recognize it as 2xbase64). For example:

V1c5MVFYSmxWMlZzWTI5dFpRbz0K decrypted to YouAreWelcome 

Coding the password twice in base64 once:

$ cat pass.txt | base64 | base64 > innocent_name.txt
$ rm pass.txt


Running the script:

$ ./root_wrap.exp "$(cat innocent_name.txt | base64 -d | base64 -d)"

Expect script:

#!/usr/bin/expect -f

set root_user root;
set root_pass [ lindex $argv 0 ];

spawn bash
expect "*$ "
send -- "whoami\r"
expect "*$ "
send -- "su $root_user\r"
expect "*?assword:*"
send -- "$root_pass\r"
expect "*# "
send -- "./whoam.sh\r"
expect "*# "
send -- "/root/rm_trace.sh\r"
expect "*# "
send -- "exit\r"
send -- "whoami\r"
expect "*$ "
expect eof

Cleanup history script /root/rm_trace.sh:


sed -i '/base64/d' /home/<user>/.bash_history
sed -i '/root_wrapp/d' /home/<user>/.bash_history
sed -i '/innocent_name/d' /home/<user>/.bash_history

Sample bash script to be run as root:


 echo "now running as root"
  • Since I will run this script in the normal user environment, doesn't that mean the root user password indicated in the script can be accessed by opening the script or reverse compiling it? – Jecht Tyre Aug 12 '14 at 18:47
  • @JechtTyre I've edited the answer to add another layer of defense. Now, it'll cat the password from randomname.txt file. Hence the password will not be shown anywhere in history and won't be possible to back engineer it. Though, you might want to rename the files root_wrapper.exp so not to give hints ;-) – Simply_Me Aug 12 '14 at 19:21
  • Doesn't change the fact that a file with the root password is accessible by a non-admin account without a prompt. – Jecht Tyre Aug 12 '14 at 21:05
  • @JechtTyre There are no free meals. If you want convenience, you must pay some price. – Simply_Me Aug 12 '14 at 21:06
  • @JechtTyre updated answer with encrypted password. – Simply_Me Aug 12 '14 at 22:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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