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.security.passwd,aix.security.user rolelist= groups=rsam visibility=1 screens=* dfltmsg= msgcat= auth_mod
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.
Who is Participating?
You can avoid being asked for your own password with "authmode=role"

Attention: After making changes don't forget "setkst"

You can avoid having to enter  "swrole" by adding "testrole" as a default role to "dopey":

chuser default_roles=testrole dopey

Kent OlsenData Warehouse Architect / DBACommented:
Hi boomer,

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,
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!)


Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

babyb00merAuthor Commented:
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 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"?

babyb00merAuthor Commented:
This is the definition of testrole from the /etc/security/roles file:

        authorizations = aix.security.passwd,aix.security.user
        id = 13
        groups = rsam

Invoking rolelist -e yields:
intft1:/home/dopey> rolelist -e

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.

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?

babyb00merAuthor Commented:
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 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"!


Just an idea - try

which passwd

file $(which passwd)

type passwd

alias passwd

as dopey.
babyb00merAuthor Commented:
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.
Could it be that enhanced RBAC is not activated on the 6100-04 system?

Check with

lsattr -EHl sys0 -a enhanced_RBAC

You should see  
attribute             value description                 user_settable
enhanced_RBAC true  Enhanced RBAC Mode True

If the value in column 2 is False, the system is using Legacy RBAC. Change it to True by issuing:

chdev -l sys0 -a enhanced_RBAC=true

Reboot and try again.


babyb00merAuthor Commented:
This is what we're getting on our test system (6100-04-01-0944)...

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.


babyb00merAuthor Commented:
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.