Date: Thu, 12 Feb 1998 13:39:09 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Charles Owens <owensc@enc.edu> Cc: hackers list FreeBSD <freebsd-hackers@FreeBSD.ORG>, freebsd-afs@FreeBSD.ORG Subject: Re: Coda FS: FBSD port done!, but development favors Linux Message-ID: <Pine.BSF.3.96.980212133040.1730A-100000@trojanhorse.pr.watson.org> In-Reply-To: <Pine.BSF.3.95q.980212112548.17150D-100000@itsdsv2.enc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Other kernel extensions we have been looking at include PAG support in the kernel -- please see recent posts on freebsd-afs for some initial discussion of this. I, also, have been meeting with Peter :). We had a fairly extensive discussion of some authentication features yesterday -- I have not looked at the inode code and as such I have not looked into possible security problems. As I understand it, the inode behavior is for performance reasons only, and as such there are presumably alternatives. I'm leaving for the airport in an our or so, but have a meeting scheduled with Peter for Wednesday of next week to discuss security concerns in various areas, including kernel code, kerberos support, and inter-server communications. My kerberos implementation is essentially complete; addressing PAG-like issues was the concentration for our last meeting. Our long-term goal is to work with various communities (such as FreeBSD, Linux) to come up with a generalized authentication extension available to distributed file systems (such as AFS, CFS) for associating tokens or priveledges with a set of processes, not just with a UID. Those of you familiar with AFS will know that if you have two incoming telnets, one can have rights to the file system while the other does not, depending on whether you have klog'd or not. There are numerous reasons for having such a service -- for example, it would be nice if daemons running as root did not have access to the same file system as a root shell elsewhere, etc. This might have uses in other areas also -- for example, it might interact with management of keys for other services, such as IPsec, where the kernel knows what authentication group each process is associated with, and provides keys as appropriate. It seems like freebsd-afs might be a better location for this discussion, however -- at least until we figure out what the requirements are? Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980212133040.1730A-100000>