On Monday 20 October 2008 17:40:21 Ahmed Sammoud wrote: > Hello again > > Well sorry if i didn't make my self clear in the first time , > What i mean is that the users can connect to it to authenticate , > > What i want to do in brief : > I want to do is a Server that allows user to connect to it ,and login to > their accounts , > the server should authenticate the users , then allow them to access their > accounts via shell access . So, a type of ssh login and then pass it along to bash/csh/zsh? > what i was thinking is making the server as a Kernel Module , > and allow all of the connections to go through the kernel module to > increase the performance , Well, *maybe* you could save a few memory clocks doing this, however, note that the authN/authZ constitutes a very small portion of any normal session. What you would end up doing, is to increase the complexity of the kernel. > and minimise the overhead of copying all of the network data from the > kernel back to the user space , > and only pass the commands that the server allows to the user space to be > executed there , > by using an interface to a a shell or a tty to execute the commands and > send the result back to the module to send it back to the user, Hmm, not a shell, but a single-shot command exectution environment? Type of ssh username@host 'command' ? > > so as you may see , i have lots of issues that i need to resolve here , > First thing was , can i authenticate users from the kernel , Only to make > sure they have an account on this machine , > NOT TO EXECUTE CODE ,the user shall only send commands that will be passed > to the user space interface to be exec. Ah, ok. I understand. My bad earlier then, I thought you wanted to allow remote entites to trigger specific kernel functions. > > Can i interface to a tty or a shell from the kernel module ? > > >>>i was thinking , to make a daemon that listens and wait commands from > >>> the daemon is the right word. A daemon resides in user space, not in kernel space :) > > module to be executed , > > Can i make some sort of multi-threading in the kernel , since multiple > users can access the server at the same time ? You have kernel threads, and you could perhaps mold these into doing what you want. > Well , That's the main issues that i have going in my mind now , > > So ,What do you Think ? I can see your point and your motivation for doing this, however; To be honest: I think this is a dead end. Sorry. You try to incorporate policy into the kernel, you want to move authentication (authN) away from where it belongs, namely in the user-land. You also try to include *a lot* of complexity into the kernel. The kernel is about functionality and making the hardware available for the users, not making the system available to remote users. Remember the UNIX-mantra: do one thing, and do it well. Don't try to make the kernel do things that other applications can do well (if not better). Just imagine what a buffer overflow exploit can do if it has access to kernel memory and kernel mode... > > Sorry again for any trouble > and Thanks a lot for your help What about looking into kernel-user memory transfer if you think it is too slow? -- mvh Henrik Austad
Attachment:
signature.asc
Description: This is a digitally signed message part.
