2

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
solaris.*
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
  • 1
    The output shown suggests the passwd file is in a read only state, within the context of your pfexec run.
    – steve
    Jul 26, 2016 at 22:02

1 Answer 1

Reset to default
1

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.

1
  • 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, 2016 at 11:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .