I created a user with useradd without specifying a password. When I try to

sudo -u theuser echo hi

I am being prompted for my admin password (unless specified otherwise in the sudoers file, of course).

su -c "echo hi" -s /bin/sh theuser

asks for teuser's password which is strange, but does not work either. Which is good.

I am now executing a


Is it safe to assume that it also cannot switch to theuser (without my explicit confirmation), even though it does not have a password set? (Or should I set an arbitrary password just to be sure)?


...su -c ... theuser asks for teuser's password which is strange,...

There is nothing strange about this but this is exactly how su is supposed to work. It might be useful to make yourself more familiar with the concepts behind su and sudo and how they differ. In short: su allows user A to execute a command as user B provided that user A can also authenticate itself as user B. In this case A can execute anything as B because A can actually be B. sudo instead allows user A to run only the specific commands in the context/permissions of user B, which root as explicitly allowed A to run in this context. Thus the authentication asks for use A to make sure that this is the user which is allowed to execute this specific command as B.

Is it safe to assume that it also cannot switch to theuser (without my explicit confirmation), even though it does not have a password set?

No, this is not safe to assume.
su needs the password of B and if there is no password set you effectively cannot login as B (note that no password set is different from an empty password set). But, sudo only needs a successful authentication of A, which the user has. If the sudo permissions are set too broad then A might be able to break out of an allowed command to execute other code.
A classic example for this case is when A is allowed with sudo to edit a specific file with vi as user B. But, it is possible to execute arbitrary external commands from within vi. This means that once A is running vi within the context/permissions of B he can also execute any other commands from within the editor session and these will also run as B.

Apart from that there might be other attack vectors which allow privilege escalation for A. There were in the past enough bugs in the linux kernel or system setup which allowed such attacks. Thus, if you are not running a system which is still supported and keep it always up-to-date there is a fair chance that your system is affected by such security bugs.

  • "he can not execute any other commands" he can, you mean?
    – phil294
    Mar 3 '18 at 7:39
  • @Blauhirn: thanks for noticing this error, I've fixed it. Mar 3 '18 at 7:44

You can check /etc/shadow to see if the password is truly empty. passwd -d theuser will set the hash as empty while passwd -l theuser will lock the account by setting the hash to !. By default most distributions are configured to disallow login with an empty password, but some specify nullok or nullok_secure for pam_unix.so, which allows login with an empty password.

Since you can't login, either the account is locked or empty passwords are disallowed. To be safe it'd be best to lock it.

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.