How to "login"

[earlz]

Ok.. my kernel is (I think) a hybrid.. I don't really care to follow any one pattern for monolithic or micro... I will follow what looks and works the best at the time.

So I am stuck though. How do I manage logins in my kernel? is the kernel even the appropriate place to do it?

My current idea is very fuzzy in my opinion. This is it:
have a securelevel variable. When it is of appropriate value, then processes can not be spawned without a valid login ID. And there would be a syscall for obtaining a login ID through a user and password combination.
My problem with this: how would I manage sudo? (su seems simple enough with this)

How have you guys done it and other kernels? cause I really have no idea if logins should be a hybrid of userspace and kernel, or just kernel(for security), or just userland(for flexibility) and which would be easiest.

[Troy Martin]

Take a peek at how linux/BSD do it. That's what I'm doing to figure out a simple login system (doing it in rmode assembly takes more time though...)

how would I manage sudo? (su seems simple enough with this)

Well, one easy way is to set the login ID to whatever root's ID is, then have the program return to the middle of the sudo program no matter what (might need to modify some ISRs here) so that you can't take advantage of being root, even though you could just sudo bash or whatever your shell is.

[Colonel Kernel]

I can briefly describe how NT does it, based on only publicly-available info of course. Every kernel resource (mutex, file, thread, process, device, etc.) is represented by an object that can be protected by an ACL (access control list). However, the actual principals (users and groups) referred to by those ACLs are managed in user space by LSASS.exe (Local Security Access Sub-System), which manages the users/groups and passwords stored in the Registry. Yet another user-space server (Winlogon.exe) handles actual logons and communicates with LSASS. Winlogon is the root of the tree of processes for a logon session. All these sub-systems communicate via IPC amongst themselves and with the kernel.

Obviously *nix concepts like su don't really exist in the NT world, but hopefully this helps anyway...