Date: Mon, 28 Jun 1999 11:44:17 +0200 From: Ladavac Marino <mladavac@metropolitan.at> To: 'Dan Seguin' <dseg@texar.com>, Ladavac Marino <mladavac@metropolitan.at> Cc: "Brian F. Feldman" <green@unixhelp.org>, FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG> Subject: RE: Connect and so on.. Message-ID: <55586E7391ACD211B9730000C11002761796AB@r-lmh-wi-100.corpnet.at>
next in thread | raw e-mail | index | archive | help
> Essentially, we're trying to mediate system calls. Read, Write, Open, > Socket calls from userland are caught, information about the calling > process (i.e. caller UID) are sent to an external source for > authorization and depending on the reply, the system call will proceed > or > not. This is the reason why the connection should be atomic and (so I > think) in the kernel. Can't have other calls going through in the > interim. [ML] If I understand this correctly, only the syscall which is being authenticated must block during the authentication. This makes the authentication atomic from the viewpoint of the syscall. The other processes/kernel supported threads may proceed. Sounds like RAGF(spelling?) scheme you're doing there. NFS daemon approach may be feasible for you, because this is exactly what it does. You have one central authentication daemon which is blocked in kernel syscall all the time, unless some other process (syscall) requests the authentication. The daemon then returns to user space, performs the neccessary authentication, and goes back into kernel with results. This is the way I would implement it, because it makes adding authentication schemes rather simple. [ML] /Marino To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55586E7391ACD211B9730000C11002761796AB>