Casper, Casper.Dik at Sun.COM wrote: > >> It is definitely not pretty which is why I filed this: >> >> 6192137 need ability to remove individual user authorizations >> >> This title should be changed however to remove both auths and >> profiles. > > Perhaps a profiles terminator "None" or some such could work for > this purpose (use only the profiles explicitly listed)
Definitely could work. > And for auths, I think you want a negation. Yep. >>> (In this particular case I allow the use of the file_dac_read privilege >>> solely for the file /etc/shadow) >> Now this is some very cool stuff! When can I get to play with it??? > > In due course unless you want to bfu a prototype (which needs a little > it of polishing perhaps before it is consumer grade) Definitely interested. Sounds like really cool stuff. Need to kill off a few existing projects but I may be interested in a bfu in a couple weeks especially when travel calms back down. >> No, it is more than that. The audit portion of this would be useful >> as it would integrate into a customer's audit framework (or tools >> that they layer on top of Solaris audit). The goal would be to better >> understand what actions are being taken on their systems - by their >> users/roles as well as services. > > So should the audit record include the contract id and the service > that maps too? I think so (assuming you are talking about building upon a process token). The FMRI and contract ID would be the most useful. In this way, you can attribute some action back to the original identity of the service (which for our purpose would be the FMRI). In the general process sense, it would actually be nice to know the effective (and perhaps permitted) privileges of the process too. Knowing real and effective UIDs are now only part of the story... g
