On Wed, 27 Jan 1999, Garrett Wollman wrote: > <<On Wed, 27 Jan 1999 18:30:15 -0500 (EST), Robert Watson > <rob...@cyrus.watson.org> said: > > > It's not clear to me, when thinking of introducing a new file (say, for > > auditing support :), what I should name it. Would it be kern_audit.c or > > sys_audit.c? > > Depends on what it is auditing. If it only auditing the basic I/O > operations, then it would go in sys_*.c. If it's a more general > kernel facility, then it goes in kern_*.c.
The spec has audit records describing all POSIX.1 calls (fork, etc). They also allow for additional audit records that are application or system defined (such as a login audit record, or a socket audit record). As such, I'll assume kern_audit.c. I do notice, however, that subr_log.c is fairly similar to what I'm doing (at least in that it has a /dev/log for a userland process, and is referenced hither and thither). > > Or, if it is POSIX.1e, would it go into a /usr/src/sys/posix1e > > directory as the posix4 realtime stuff did (assuming that support > > for additional features from that posix draft were going to be > > forthcoming)? > > Giving the unhelpful tendency of Project 1003 to renumber its > standards after-the-fact (or fold them into the main 1003.1 document), > I would suggest against using committee identifiers like this. This is further confused by the fact that this draft (as I understand it) will not be made a standard. However, Solaris and Linux both seem to have ACL implementations, and Linux the Capabilities implementation. (Linux does not have file system support for these, however) The auditing code will be useful for a project I'm working on, so I figured I'd do that first. > If it's controlled by a compile-time option, it should probably be > called POSIX_AUDITING rather than POSIX_1e or something of that > nature, since your statement implies that there is a useful > granularity of features. The components of 1e (and 2c, the userland utilities associated with 1e): ACLs Capabilities Auditing MAC Information Labels The order of interest for me is Auditing, Capabilities, ACLs, and then the remaining two. Auditing has immediate benefit to a project of mine; it requires fairly comprehensive userland library support, so it may take a few weeks. To do ACLs, I need some place to store ACLs, such as additional file forks or a centralized file like quotas use--I'm not sure I want to deal with them yet, although they would be nice to have. I have not reviewed Capabilities in detail--they don't seem horribly useful to me in terms of the standard capabilities they define--however, adding some of our own that are more tailored to BSD would be useful. MAC and Information Labels are clearly useful--that is, if someone wants to try and make FreeBSD Bx rated :). I'll do these if I have time, probably this summer. For now, I'll add options: POSIX_AUD POSIX_ACL POSIX_CAP POSIX_MAC POSIX_INF Which are consistent with the run-time defines associated with the features (the run-time defines have _'s in front). Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
