I guess I'm just not getting it!
I'm trying to use RBAC on an AIX 6.1 system to authorize a subset of users to perform user administration. In particular, I'd like for this group to be able to administer passwords. I created a role named "testrole" with the following definition:
testrole authorizations=aix.securit
e=INVOKER id=13
I've created a test account named "dopey" to which I've added this role. What I can't figure out is why I'm getting the following error when, as dopey, I try changing the password of another account.
ksh[22]: passwd: 0403-006 Execute permission denied.
testrole authorizations=aix.securit
e=INVOKER id=13
I've created a test account named "dopey" to which I've added this role. What I can't figure out is why I'm getting the following error when, as dopey, I try changing the password of another account.
ksh[22]: passwd: 0403-006 Execute permission denied.
Did you check (as dopey) with "rolelist" that dopey is indeed authorized to use "testrole?
Did you issue (as root) "setkst" to update the kernel tables with your new settings?
Did you issue "swrole testrole" before attempting to use the "passwd" command?
(dopey will be asked for their own password!)
wmp
Did you issue (as root) "setkst" to update the kernel tables with your new settings?
Did you issue "swrole testrole" before attempting to use the "passwd" command?
(dopey will be asked for their own password!)
wmp
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
This is what the dopey account looks like
dopey id=5001 pgrp=rsam groups=rsam,staff home=/home/dopey shell=/usr/bin/ksh gecos=Test Account login=true su=true rlogin=true daemon
=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=comp
at logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=1 minother=1 mindiff=0 max
repeats=2 minlen=6 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=2097151 cpu=-1 data=262144 stack=65536 core=
2097151 rss=65536 nofiles=2000 roles=testrole
And yes, I ran setkst and swroles.
dopey id=5001 pgrp=rsam groups=rsam,staff home=/home/dopey shell=/usr/bin/ksh gecos=Test Account login=true su=true rlogin=true daemon
=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=comp
at logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=1 minother=1 mindiff=0 max
repeats=2 minlen=6 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=2097151 cpu=-1 data=262144 stack=65536 core=
2097151 rss=65536 nofiles=2000 roles=testrole
And yes, I ran setkst and swroles.
Ok,
dopey looks good.
Please post the entry for "testrole" from /etc/security/roles exactly as it appears there.
The way you posted it in your Q it will not work due to some syntax errors (copy-and-paste ?)
What happens when dopey issues "swrole testrole" (not "swroles ...")
swrole should ask for dopey's password and then start a new shell.
What does dopey get inside this new shell with "rolelist -e"?
dopey looks good.
Please post the entry for "testrole" from /etc/security/roles exactly as it appears there.
The way you posted it in your Q it will not work due to some syntax errors (copy-and-paste ?)
What happens when dopey issues "swrole testrole" (not "swroles ...")
swrole should ask for dopey's password and then start a new shell.
What does dopey get inside this new shell with "rolelist -e"?
ASKER
This is the definition of testrole from the /etc/security/roles file:
testrole:
authorizations = aix.security.passwd,aix.se
id = 13
groups = rsam
Invoking rolelist -e yields:
intft1:/home/dopey> rolelist -e
testrole
I did not execute the swrole command prior to running rolelist because I've already used the chuser command from your previous response to set a default role for this user.
testrole:
authorizations = aix.security.passwd,aix.se
id = 13
groups = rsam
Invoking rolelist -e yields:
intft1:/home/dopey> rolelist -e
testrole
I did not execute the swrole command prior to running rolelist because I've already used the chuser command from your previous response to set a default role for this user.
Ok,
id = 13
should be the first line following the "testrole:", and there must be
an empty line between the end of the previous role definition and
this stanza.
Don't forget to issue "setkst" after making changes to any RBAC database!
Done this, dopey must be able to issue "passwd"!
This message "Execute permission denied" seems a bit strange to me!
Normally one would expect "3004-664 You are not authorized to change ..."
What do you get with ls -l /usr/bin/passwd" ?
It should look like this: "-r-sr-xr-x 1 root security ... ..."
Does it?
id = 13
should be the first line following the "testrole:", and there must be
an empty line between the end of the previous role definition and
this stanza.
Don't forget to issue "setkst" after making changes to any RBAC database!
Done this, dopey must be able to issue "passwd"!
This message "Execute permission denied" seems a bit strange to me!
Normally one would expect "3004-664 You are not authorized to change ..."
What do you get with ls -l /usr/bin/passwd" ?
It should look like this: "-r-sr-xr-x 1 root security ... ..."
Does it?
ASKER
It does... the passwd access permissions that is.
The problem goes away if I add dopey to the security group. I'm just not sure why that works or, more importantly, why it's necessary.
The problem goes away if I add dopey to the security group. I'm just not sure why that works or, more importantly, why it's necessary.
The membership in the "security" group makes all this RBAC stuff obsolete.
It's a feature built into AIX since long that members of this group can change passwords and attributes
of other users/groups, except for those users/groups flagged as being "administrative".
(You must use "chuser" or "mkuser" or "passwd" (or smitty), "useradd", "userdel" or "usermod" will not work).
OK, I couldn't resist:
In the meantime I added your role definition to my /etc/security/roles file, updated a testuser (which is NOT in the security group!) with "chuser roles=...." and "chuser default_roles=...", issued "setkst" and - "passwd otheruser" works without any issue.
It turned out that the blank line between roles is indeed important!
So I must admit that I'm just clueless why this shouldn't work for you...
I can only suggest double checking all your definitions in /etc/security/roles, /etc/security/user.roles and /etc/security/user.
Additionally check (as root) with
lsauth -a roles | grep testrole
if all authorizations are present.
Instead of "testrole" you could try using the system defined role "AccountAdmin" which will do nearly the same as "testrole" should.
And I keep telling you: Don't ever forget "setkst"!
wmp
It's a feature built into AIX since long that members of this group can change passwords and attributes
of other users/groups, except for those users/groups flagged as being "administrative".
(You must use "chuser" or "mkuser" or "passwd" (or smitty), "useradd", "userdel" or "usermod" will not work).
OK, I couldn't resist:
In the meantime I added your role definition to my /etc/security/roles file, updated a testuser (which is NOT in the security group!) with "chuser roles=...." and "chuser default_roles=...", issued "setkst" and - "passwd otheruser" works without any issue.
It turned out that the blank line between roles is indeed important!
So I must admit that I'm just clueless why this shouldn't work for you...
I can only suggest double checking all your definitions in /etc/security/roles, /etc/security/user.roles and /etc/security/user.
Additionally check (as root) with
lsauth -a roles | grep testrole
if all authorizations are present.
Instead of "testrole" you could try using the system defined role "AccountAdmin" which will do nearly the same as "testrole" should.
And I keep telling you: Don't ever forget "setkst"!
wmp
Just an idea - try
which passwd
file $(which passwd)
type passwd
alias passwd
as dopey.
which passwd
file $(which passwd)
type passwd
alias passwd
as dopey.
ASKER
I found out that the new role I've defined (testrole) works on our AIX system running 6100-06-03-1048. It does not work on our system running 6100-04-01-0944.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
This is what we're getting on our test system (6100-04-01-0944)...
enhanced_RBAC true Enhanced RBAC Mode True
enhanced_RBAC true Enhanced RBAC Mode True
Too bad,
this would have been an easy solution.
I researched in IBM's support databases and didn't find an APAR (not even the smallest hint)
about a bug like this one in RBAC under AIX 6.1 TL4.
So I think you should compare once more both systems in regard to the concerned files /etc/security/roles, /etc/security/user.roles and /etc/security/user.
Besides that, I have to admit that I'm out of ideas now.
wmp
this would have been an easy solution.
I researched in IBM's support databases and didn't find an APAR (not even the smallest hint)
about a bug like this one in RBAC under AIX 6.1 TL4.
So I think you should compare once more both systems in regard to the concerned files /etc/security/roles, /etc/security/user.roles and /etc/security/user.
Besides that, I have to admit that I'm out of ideas now.
wmp
ASKER
No worries. We do intend to apply a tech-level upgrade to that system... eventually. Regardless, I got a lot of good information from you... as usual. Fortunately, the target system - for which all of this testing is a precursor - is working as advertised.
You're overthinking this. :)
The shell is informing you that the user has no permission to execute the passwd statement.
You should probably create a group permission for "authorizations" to execute passwd.
Good Luck,
kent