AIX

Thank igalvarez for your suggestion

Finally, I have created an account ~ root, using RBAC

Thanks all guys, too

I have got a problem.
I have added all default roles to my user ( root2 )

Code:

lsuser -a roles root2
root2 roles=AccountAdmin,so,FSAdmin,sa,BackupRestore,DomainAdmin,SecPolicy,SysBoot,SysConfig,isso

but this user can't execute this command

Code:

bootlist -m normal -o

Then I maked "testrole" and added that command to it.
The problem is : when I "swrole" to testrole ( only one role ), I could execute that command. But when I "swrole" to testrole and these default role ( 11 roles in total ) , I couldn't execute that command anymore .

Somebody knows how to fix this ???

bootlist is a privilege command as shows:

lssecattr -c -F ALL

Code:

/usr/bin/bootlist:
        accessauths=aix.system.boot
        innateprivs=PV_DAC_R,PV_DAC_X,PV_KER_VARS
        inheritprivs=PV_AU_ADD,PV_AU_PROC,PV_DAC_R,PV_DAC_W,PV_DAC_X,PV_DEV_CONFIG,PV_KER_VARS
        secflags=FSF_EPS

In red you can see it belongs to authorizations 'aix.system.boot'
So, if you go to AIX roles

lsrole -f ALL

this authorization is part of role 'SysBoot'

I think you need to add the role 'SysBoot' to your root2 user

Hope this helps.

You got already advice about how to deal with your imminent problem. I would like to add some general remarks about RBAC: my professional experience is to better stay away from RBAC (as well as ACLs, for that matter, and for similar reasons) and restrict yourself to the classical user rights management UNIX offers.

The UNIX privilege model is very simple and - at first sight - not very flexible. On the other hand, as long as you stay within its boundaries it can be managed with an absolute minimum of effort. Any query or change, regardless of addressing a single user or many, a single file or many, can be done in a minimum of steps and in most cases only one command is needed.

RBAC (and ACLs as well) offer the ability to use a much more fine-grained model. Allow userA to execute cmdB but not cmdC and userB the other way round, etc.. This is an alluring prospect but if you really start to put all these offered capabilities into practice and quite soon you have system which is way too complex to be handled effectively. Instead of a simple "ls -l" you need to cross-corelate long lists of "userA is able to execute cmdB only when ... and then only at ... but not in the presence of ... except if ...". Once you got through all the ifs, whens, and excepts you probably have forgotten what you originally wanted to do in first place.

In short: UNIX privilege management is very simplistic, but it is so for a reason: stick with it and you always have a manageable system. Use all the fancy additional possibilities (RBAC, ACLs, even both) and very likely you will be able to solve a singular problem more easily but in the long run end up with a system which is hard (if not impossible) to manage and a privilege structure which is neither easily nor quickly adapted to changing demands.

I hope this helps.

bakunin

RBAC, as bakunin said, it's not easy to manage. But it's not impossible either to create your own roles and enable it on your system.
In our case, we have more than 6 system admins and if all of them use root account, it's dificult to audit your system. Here's where RBAC is useful, because you can enable it for all system administrator and everyone do the work ( as root), but using with their users.

Also, it's very possitive and welcomed by auditors.

To teel you the true, we are happy with RBAC.

Cheers

But why waste time when it takes you less than 5 minutes to configure sudo to do the same? Even better - e.g. without having to enter a passwd when root...
All the best

Hi vbe,

First, I'm not saying RBAC is better than others solutions you have said above. I just told bobochacha29 what we use in our enviroment.

My waste of time is simple:
There're a lot of users logged on on production enviroment. All these users are from differents groups, execute differents commands, etc etc. Some of them SU to another common account to make their tasks. Others system admins used only root account. So, after a an audit we deciced to use RBAC, so everyone use its personal account.