On Fri, 25 Jun 1999, Ladavac Marino wrote:

> > -----Original Message-----
> > From:       Dan Seguin [SMTP:d...@texar.com]
> > Sent:       Friday, June 25, 1999 5:26 PM
> > To: Brian F. Feldman
> > Cc: FreeBSD Hackers
> > Subject:    Re: Connect and so on..

> > As I said earlier in this post, I need to open a connection to the
> > outside
> > (presumably) from the KERNEL. The reason for this is that the calling
> > process has no knowledge of the connection, and the connection,
> > communication, response from other end, and closing of connection must
> > be
> > one atomic, discreet event that will not get interrupted. I assumed
> > that
> > this would have to be done from the KERNEL but maybe I'm wrong here.

>       [ML]  From your original mail it is not obvious why this has to
> happen from the kernel, but I assume that you need to have the UID of
> the caller and the safest way would be to get it from the kernel.  If
> that is the case, you could take a look at the way nfssvc(?) works going
> back into user space for authentication.  There are, however, other
> authentication schemes which can be implemented keeping everything in
> user space--take a look at the secure RPC implementation (Bill Paul was
> working on that some time ago, IIRC).
> 
>       If you can tell a bit more about the problem grounds, perhaps an
> easier solution can be found.
> 
>       /Marino

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.

As a side note, I just started working on this last week after having
shelved it for so long (that was when 2.2.8 (9)? was the latest). Doug
Rabson and others helped with the system call stuff and it works
beautifully. If any of you remember, thanks for the pointers!

Since then, I've been going through the 4.4BSD implementation guide and
learning lots. My knowledge isn't complete, but getting better. I
appreciate the help I get here, it's even better than Usenet use to be
before it got corrupted.

Dan Seguin





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to