I've been playing around with a Solaris 11 system, where I've made several user-accounts for myself. Anyway, I gave one of my unprivileged account the solaris.* auth, and then tried to give another unprivileged account the System Administrator profile:

user$ auths
user$ pfexec usermod -P"+System Administrator" user2

This failed with the following error-message (yes, repeated three times):

/usr/lib/passmgmt: Password file(s) busy.  Try again later
/usr/lib/passmgmt: Password file(s) busy.  Try again later
/usr/lib/passmgmt: Password file(s) busy.  Try again later

I've "tried again later" - even after just rebooting - and each time I've get the same result. This is a completely different error than when a user without the solaris.* (or one of the assign-auths) tries the command.

I've also tried to explicitly add auths regarding assigning profiles, auths and roles - eg. solaris.profile.assign - in addition to solaris.* (like how solaris.grant had to be explicitly assigned); but that didn't help (nor show up when I did a auths - only solaris.* showed).

I have however successfully used usermod to assign these things while root or while using a user with the Primary Administrator profile (I copy-pasted in from a previous Solaris-version).

However I really thought solaris.* - or for that matter just the solaris.profile.assign - ought to have been enough to use usermod to give privileges to other users...

So what does the (triple) error-message mean? Why doesn't it work? And if it shouldn't work, why not? And what would be the correct "least" combination of auths and/or profiles to make it work?

  • 1
    The output shown suggests the passwd file is in a read only state, within the context of your pfexec run. – steve Jul 26 '16 at 22:02

Why doesn't it work?

The error messages

/usr/lib/passmgmt: Password file(s) busy.  Try again later
/usr/lib/passmgmt: Password file(s) busy.  Try again later
/usr/lib/passmgmt: Password file(s) busy.  Try again later

likely mean you don't have permission to create a file in /etc.

The only source of that error message that I can find is in the passmgmt source code and is generated when passmgmt fails either to create the file /etc/.pwd.lock or can not actually lock the file if it already exists.

passmgmt, and likely many other Solaris utilities, attempt to lock the password files with an /etc/.pwd.lock file. (source code link for locking the password files).

Given that you can successfully use usermod while root, this doesn't look like a problem where an errant process holds a lock on /etc/.pwd.lock, so the only failure per the published Illumos source (admittedly a bit out-of-date now) that generates the error messages that you see is a failure to create /etc/.pwd.lock, almost certainly because your process doesn't have write permissions to /etc.

That's why it's failing. Unfortunately, I don't have the time to research whether it should fail or not.

  • Seems reasonable.... Neither do I know if it should work or not - still having an auth so that a user can do something (eg. solaris.profile.assign), but it turns out he can't anyway because he doesn't have the permission to make a lock, does seem a bit redundant... I guess the difference when doing it through profiles, is that profiles doesn't just assigns auths and other profiles; but also assigns the ability run specific commands as system-users (sometimes including root) through /etc/security/exec_attr . – Baard Kopperud Jul 27 '16 at 11:00

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.