This content has been marked as final. Show 7 replies
I do not completely understand what you are looking for. Perhaps it would help if you explained, for which purpose you want to use your new role.
In short, a role is simply a user account, to which you cannot login directly. As to every user account, rights are assigned to each role. And as for every user account, you have to provide a password for it.
If you want to switch to a role without password, this is nearly the same as extending the rights of your account.
This is possible by assigning additional profiles to it via /etc/user_attr. Privileged commands, written by you, and connected to these profiles, can be defined in /etc/security/exec_attr.d/local-entries. These commands can be called via pfexec, see pfexec(1), which grants privileges (e.g. uid=0) for just the call.
See also user_attr(4), prof_attr(4), exec_attr(4) and the "SEE ALSO" sections in there.
Profiles can be chosen from the predefined profiles in /etc/security/prof_attr.d, or they can be self-assembled from these profiles and authorizations from /etc/security/auth_attr.d.
New profiles should be stored in /etc/security/prof_attr.d/local-entries.
Simply speaking if I'm user monza who has been granted role 'somerole' then if do
<pre>monza$ su - somerole</pre>
then I'm prompted for a password. I would like to avoid being prompted for a password.
In Solaris 10 I could do that as explained above. In Solaris 11 I do not know how to do it. It seems that in Solaris 11 simply changing 'somerole' to a NP (no password) account is no longer enough.
Please try in Solaris 11.1 with the 'passwd -d myrole' again, that really should work when roleauth=role (ie the default).
There were some changes in how the passwd(1) state transistions work between Solaris 10 and 11 and then again in 11.1 (to bring back some of the things that Solaris 10 allowed that Solaris 11 did not).
Though if you don't want authentication and you don't need a shared home directory for a shared account then I would recommend you grant the RBAC profiles to the user. You may also want to change the users login shell to be prefixed with 'pf' eg '/usr/bin/pfbash if you don't want them to always have to prefix commands in the profiles with 'pfexec'
So I thought I would prove to you that this doesn't work in Solaris 11.1.
Here is exactly what I do:
<pre>root@minisrv:~# cat /etc/release</pre>
<pre> Oracle Solaris 11.1 X86</pre>
<pre> Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.</pre>
<pre> Assembled 19 September 2012</pre>
<pre>root@minisrv:~# roleadd -d /export/home/myrole -m myrole</pre>
<pre>root@minisrv:~# passwd -d myrole</pre>
<pre>passwd: password information changed for myrole</pre>
<pre>root@minisrv:~# usermod -R +myrole monza</pre>
Then I log into user 'monza' and do as follows:
<pre>monza@minisrv:~$ su - myrole</pre>
What am I doing wrong ?
perhaps this will help:
Deletes password for name and unlocks the
account. The login name is not prompted for pass-
word. It is only applicable to the files and ldap
If the login(1) option PASSREQ=YES is configured,
the account is not able to login. PASSREQ=YES is
the delivered default.
By the way:
PASSREQ=YES is the default in /etc/default/login
If I interpret passwd(1) correctly, after performing passwd -d, login to your "myrole" in any way is impossible, until you change PASSREQ.
Thank you. That has solved the problem.
Obviously the reason why I've not been observant about the PASSREQ setting before is because of the bug you mention.
I've tested on Solaris 10 u10 and in that release it is perfectly possible to make a role without a password and make it work without setting PASSREQ to 'NO'. So I'm leaning towards that the bug you mention about lack of enforcement of PASSREQ setting was never fixed in any version of Solaris 10.
This will surely break some updates to Solaris 11 but now that we know how to fix this it is no big deal.
Again : mille grazie