| From | Sent On | Attachments |
|---|---|---|
| Andrew R. Reiter | Aug 17, 2001 6:25 am | |
| Robert Watson | Aug 19, 2001 5:15 pm | |
| Andrew R. Reiter | Aug 20, 2001 12:32 am |
| Subject: | Re: login_cap | |
|---|---|---|
| From: | Robert Watson (rwat...@freebsd.org) | |
| Date: | Aug 19, 2001 5:15:59 pm | |
| List: | org.freebsd.freebsd-audit | |
Would this make use of the setlogincontext() code in libutil? If so, I'd be very happy to see that used more pervasively through the system. In particular, using LOGIN_SETALL with appropriate bits substracted, rather than specifying individual bits. The reasoning for this is that my MAC code uses a new LOGIN_SETLABEL flag, and I noticed a number of existing uses of setlogincontext() that set only specific bits but leave out parts of the context setup. Likewise, places in the system where uids/etc are manually configured, resulting in incorrect setting of additional groups, resource limits, etc. Given that appropriate enforcement of system resource limits is now vital to maintaining multi-user systems, being consistent about enforcing them in all situations is very important.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project rob...@fledge.watson.org NAI Labs, Safeport Network Services
On Fri, 17 Aug 2001, Andrew R. Reiter wrote:
Hey,
Im wondering if there's any real interest for patches to be made for some services so that they do login class, etc authentication? Such an example would be for atrun.c in libexec/atrun/.
In my opinion, it is probably worth doing and getting commited, but if no one would commit the patches, I dont see a point in doing them :-)
btw, if you're unfamiliar with login caps, check out login_cap(3) and login_class(3).
Andrew
*-------------................................................. | Andrew R. Reiter | ar...@fledge.watson.org | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message





