From owner-freebsd-hackers Mon Jun 28 2:47: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id 1176B14C96 for ; Mon, 28 Jun 1999 02:47:05 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id ; Mon, 28 Jun 1999 11:50:07 +0200 Message-ID: <55586E7391ACD211B9730000C11002761796AB@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: 'Dan Seguin' , Ladavac Marino Cc: "Brian F. Feldman" , FreeBSD Hackers Subject: RE: Connect and so on.. Date: Mon, 28 Jun 1999 11:44:17 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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