Darren J Moffat wrote: > Roland Mainz wrote: > > Is there a nameservice-independent way to obtain the values for > > "user_attr" and "publickey" from a shell script (if not I would propose > > to add a extension to "getent") ? > > publickey no there isn't. > > For user_attr it depends which values you want.
I want the "raw" values as returned by |getuserattr()|, |getprofattr()|, |getprofattr()| etc. ... /usr/bin/getent should just return the matching values, either for the admins, users or shell script to use. > user_attr is a little problematic because in some cases it isn't just > user_attr you need to look at but you might then need to look at > prof_attr, auth_attr and exec_attr as well as policy.conf. > > There are a couple of shell tools for some of the user_attr data. > > auths(1) will tell you all the authorisations a user has from user_attr, > all included profiles and defaults from policy.conf. > > profiles(1) will tell you all the profiles a user has assigned to them > from user_attr, and policy.conf and any profiles included in a profile. > > roles(1) will tell you the roles a user has - currently you can only > assign a role directly in user_attr(4) but we want to change that so you > can do it as part of a profile in prof_attr(4) as well. Ok, but all these tools only return mangled versions of the data and not the "raw" (or better: unchanged) values as returned by the native library calls, right ? > That still leaves: > > project, defaultpriv, limitpriv, lock_after_retries, > idletime, idlecmd, labelview, clearance, min_label, type. > > For the user_attr(4) database what exactly is it you are trying to do > from shell script ? Possible usage would be a system admin to figure out whether the system "sees" the changed attributes in a way he/she would expect it (e.g. change/modification verification) ... I could imagine futher usage but right now the primary problem is that there is no direct access to these data except looking at /etc/nsswitch.conf and then implement hand-crafted code for each possible backend type - and that's not really usefull... ;-( A better example would be our script which changes the X11 authentification from MIT-MAGIC-COOKIE-1 to SUN-DES-1 if the user has propper DES/DH credentials. If you have access to NIS+ it's no problem - but obtaining the data from other types of directory backends can be a serious pain for shell scripts (and if we add "publickey" to /usr/bin/getent IMO we should add the other items in /etc/nsswitch.conf in one step (with the limitation that the changes should be easy and obvious), too - just to avoid that someone falls in the same pit as I did long ago... ;-( ). ---- Bye, Roland P.S.: Reply-To: set to OpenSolaris Shell discussions <[EMAIL PROTECTED]> -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
