Date: Sun, 06 Sep 1998 22:39:06 -0700 From: Mike Smith <mike@smith.net.au> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: lkm hooks for passing (blah) via file descriptors Message-ID: <199809070539.WAA11569@word.smith.net.au> In-Reply-To: Your message of "Fri, 04 Sep 1998 13:18:45 EDT." <Pine.BSF.3.96.980904131345.17220B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > As part of my research work on adding authentication/authorization tokens > to the FreeBSD kernel, I have two sets of patches that have been useful > for me under 3.0-CURRENT: > > 1. Patches to kern/uipc_socket.c (and others) to allow lkm's to hook three > spots in the arbitrary kernel-stuff passing code -- internalize(), > externalize() and gc(). This also involved cleaning up the file > descriptor passing code a little, etc. This code appears to run fine on > all the machines I have tested it on. Having this submitted as a PR would be very handy. If you could summarise the effects of "cleaning up a little" in the PR docco, that would help make a case for this. > 2. Adding a p_auth pointer in the proc structure (zero'd at fork for the > new process, although at_fork() lkm's can modify it immediately after the > fork, and based on the parent value) for hooking arbitrary authentication > or authorization information into the proc structure. Do you have a standard mechanism for chaining items off this pointer, or do you envisage only ever having one consumer at a time? How about a generalised interface that puts the current credentials there as well? > Would any of these patches be of interest for 3.0-CURRENT? The first > patch is something that I find useful, but that might not be so useful for > others. The second might be of more general use; especially if we stick > want to stick in posix capabilities via an optional lkm (a likely first > implementation -- I am ordering posix .6 this afternoon). I think that the lack of commentary here would tend to indicate that nobody violently objects, but perhaps that not enough people understand the ramifications of your changes. If you could paint them in the context of the kernel-wide authentication infrastructure you described earlier, in a fashion suitable for consumption by TV-age minds, you might raise some more noise. Basically, the suggestions both seem sound. The greatest concern which might be raised against the second patch would be that it's perhaps not being made in the context of a larger and more coherent vision for authentication management. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809070539.WAA11569>