Date: Mon, 5 Jul 1999 17:22:29 -0400 (EDT) From: Dan Seguin <dseg@texar.com> To: Ladavac Marino <mladavac@metropolitan.at> Cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG> Subject: RE: Connect and so on.. Message-ID: <Pine.BSF.4.05.9907051557460.9568-100000@pak2.texar.com> In-Reply-To: <55586E7391ACD211B9730000C11002761796AB@r-lmh-wi-100.corpnet.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jun 1999, Ladavac Marino wrote: > > > 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. Sorry about tardy response, I've been away. What you describe above is correctly expresses what I was trying to say. Could you point me to more about this (RAGF) scheme? > > 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 > Excellent, thank you. Although, looking through NFS code doesn't sound like fun. Oh well, time to pay my dues. Something else I need to look into is how to effeciently pass info back and forth from kernel space to user space and vice-versa. (See above for brief background of what I'm attempting to do). For every syscall being tracked/authenticated, a record is constructed and needs to be sent to the (userland) comms daemon that will send it to another server and await a response. In the mean time, the process making the syscall is blocked. Understandably this will really cut off process performance at the knees, but then again this a proof of concept project. One can easily imagine the processes being blocked starting to backup, since the comm daemon is competing for processor time, even if every entry into the kernel by (arbitrary) tracked syscalls resets the priority of the comms daemon to a higher level. (I'm trying to let the daemon get as much of the processor as possible to complete what it is doing. It releases it's quanta whenever it needs to wait for something). The comms daemon would keep a table of records received from the kernel to be authenticated, and only mark it as read when it has received a response (while being preempted many times), so that at the next arbitrary tracked syscall, the kernel would look at this table, look at all the status word fields (one per record) and read in the (response) records, if any, and mark these slots as unused for later use. This table would have to be in userland, with a single byte status field for every record. The table would have fixed size records, say 1k per entry. The seond field holds the PID and the third is free form. The status field would act as a signal to the kernel that a response was received. The kernel would read the status and PID and unblock the process, and either let the syscall proceed or not. Can't use a restart here, because, as I understand it, this would create another syscall, and hence a loop. Now, what I need to know is what is the best way to move this info over the fence, back and forth. Seems copyin() and copyout() are used throughout kernel code. With a table with fixed size records, I would simply need to loop through every status byte with copy*(addr + size(record)) to find out the responses, without (*ahem*) being interrupted. Is there an easier/better/more effecient subsystem to use that I don't know about? There are a lot of timing issues here, and I'm sure I've missed some. The comms daemon becomes a huge bottleneck for the processes that happen to make syscalls that are being tracked, but I don't see a better way. One of the things that the comm daemon would do is cache a lot of these recurring requests so that it wouldn't have to go "outside" to respond to the auth request. Also, if someone can point me to some books/papers/soliloquies of how to effeciently manage a shared table, I'd be grateful. 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?Pine.BSF.4.05.9907051557460.9568-100000>