Date: Fri, 16 Mar 2001 22:00:43 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: Terry Lambert <tlambert@primenet.com> Cc: crossd@cs.rpi.edu (David E. Cross), freebsd-arch@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: idle wonderings about 'struct pcred' Message-ID: <200103170300.WAA92623@cs.rpi.edu> In-Reply-To: Message from Terry Lambert <tlambert@primenet.com> of "Fri, 16 Mar 2001 19:57:38 GMT." <200103161957.MAA16801@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Good idea. I have been pushing for something like this for years. Heh... and I was about to get the asbestos undies on. Good to know I am not totally insane in all of my musings :) > > It would let you "preauthenticate" (ala a "password cache" on > login, or an explicit "add credential for XXX" program) for things > like per user authentication for an SMB or Appletalk client, on > a per user basis (most SMBFS implementations are useless, because > they do not offer per user security, unless you are using a single > user client OS like Windows). *nod*, This was the exact type of idea that I had in mind. > The next neat step would be a "session manager", which would sit > on an fd listening for "new credential needed" requests from the > kernel, and interrogating the user. > > For example, you could have a KDE program that sat there and waited, > and when the user tried to access a password protected file, a network > share, /dev/io, the CDROM, tape backup unit, mount an FS as someone > other than root, or whatever, it could pop up a dialog and say: > I have no idea even how to begin that part. How would 'sessiond' know which terminal to forward the request to? Could it even know that 'terminal' is an xterm on a remote machine? What if the user is logged in multiple times (on console in the office, and also from home). What I had in mind in the short term is a series of utility programs (like klog for afs) that would add the required auth data (via syscalls) to the proc structure. And various parts of the kernel would update the structure as they progressed. To use the kerberos example... :) the PAM module krb5 auths the user, gets the TGT and hands it off to the kernel. The filesystem layer accesses the auth structure for auth data of type PCRED_AUTH_KRB5, and service filesystem/HOST@REALM. Not finding it, it would do whatever it takes to get it (alert the user, issue the krb requests itself, whatever) and issue the commands to the krb5 auth module to insert the new key. This last step implies that the auth modules within the kernel will have some sort of API. This is clearly needed, but I would not consider any sort of standard API since the various methods differ so dramatically in the type of data and how it is handled. What does need to be standardized is a method of reference counting and sharing data among proc structures (apparently the current method has some of this, not sure of the details yet). -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103170300.WAA92623>