Hi, I also agree with most things already said. I would like to add that the way documentation is currently handled involves too much copy + paste of almost meaningless descriptions, but I haven't found a very good alternative either. (maybe adding a type attribute to the param xml and generating a summary based on that could work in the most common cases) On 6/12/20 3:02 PM, Russell Coker wrote: > Does staff_r even make sense when you could just use >>> different MCS categories for different users? >> Yes, as user_r cannot reach admin roles whereas staff_r can. > The user identity has a permitted list of roles, you can have users who are > permitted user_r and sysadm_r and users who are only permitted user_r. The > original benefit of staff_r was to protect staff from attacks by user_r > accounts, but we can do that protection with the identity based constraints. I would propose replacing user based constraints with role based constraints: The user part of the context (normally) doesn't change after login, this means that files edited by a staff_u user become inaccessible by anyone else, even if sudo is used to change to staff_u:sysadm_r:sysadm_t, but reducing the user based constraints for staff_u is undesirable. Those are just my 2 cents, bauen1
