Linux: Is there a non-root shell command to find if a user account is enabled or not?

5,258

Solution 1

You can add the following to /etc/sudoers:

%admin   ALL = NOPASSWD: /usr/bin/chage -l *

This will give anyone in the admin group the ability to run commands like this, without being prompted for a password:

sudo chage -l username

If you want to run this from a cron job or such, you'll need to add the following to /etc/sudoers:

Defaults:%admin   !requiretty

(Don't edit /etc/sudoers directly; instead, run sudo visudo)

Solution 2

No, there isn't. As a non privileged user it would be a potential security risk too allow such users access to /etc/shadow. I believe that for all modern linux distributions password hashes and additional account info has been moved to /etc/shadow from /etc/passwd to eliminate a security hole. If your system uses shadow passwords the "!" at the beginning of a password hash will only be visible and present in /etc/shadow and therefore no accessible to a regular, non-privileged user.

Share:
5,258

Related videos on Youtube

weiji
Author by

weiji

Updated on September 18, 2022

Comments

  • weiji
    weiji almost 2 years

    Is there a non-root shell command that can tell me if a user's account is disabled or not?

    Please note that there is a fine distinction between LOCKING and DISABLED:

    • LOCKING is where you prepend ! or * or !! to the password field of the /etc/passwd file. On Linux systems that shadow the passwords, this marker flag may be placed in /etc/shadow instead of /etc/passwd. Password locking can be done (at a shell prompt) via password -l username (as root) to lock the account of username, and the use of the option -u will unlock it.
    • DISABLING an account is done by setting the expiration time of the user account to some point in the past. This can be done with chage -E 0 username, which sets the expiration date to 0 days after the Unix epoch. Setting it to -1 will disable the use of the expiration date.

    The effect of locking to to prevent the login process from using a supplied password to hash correctly against the saved hash (by virtue of the fact that the pre-pended marker character(s) are not valid output character(s) for the hash, thus no possible input can ever be used to generate a hash that would match it). The effect of disabling is to prevent any process from using an account because the expiration date of the account has already passed.

    For my situation, the use of locking is not sufficient because a user might still be able to login, e.g. using ssh authentication tokens, and processes under that user can still spawn other processes. Thus, we have accounts that are enabled or disabled, not just locked. We already know how to disable and enable the account - it requires root access and the use of chage, as shown above.

    To repeat my question: is there a shell command which can be run without root privileges which can output the status of this account expiration info for a given user?

    If it helps any, this is intended for use on a Red Hat Enterprise 5.4 system. The output is being returned to a java process which can then parse the output as needed, or make use of the return code.

    • James T Snell
      James T Snell almost 13 years
      I can cat my /etc/passwd file as a non-root user. Can you not do the same?
    • weiji
      weiji almost 13 years
      @Doc - Can you comment on the difference between LOCKED and DISABLED? The passwd file does not contain the account expiration info as I understand it. I mention this in my question body.
  • weiji
    weiji almost 13 years
    I have edited my question to clarify the difference between locking and disabling.
  • Terpion
    Terpion almost 13 years
    Locked or disabled, issue remains the same, that information is stored in /etc/shadow and therefore inaccessible to non-privileged user. However, since you are using RHEL look into setting up a system account and give it read permission on /etc/shadow via ACL.
  • Alastair Irvine
    Alastair Irvine about 10 years
    This will not work on any recent Unix/Linux system, because the encrypted passwords and the lock flag (as well as all other password-related information) are now stored in /etc/shadow .