Messages in this thread | | | Date | Fri, 12 Dec 1997 13:22:19 -0500 (EST) | From | "Adam D. Bradley" <> | Subject | Re: Conditional SymLinks |
| |
Albert,
> > I've pondered ways of going about this. The problem is, the > > uid-to-home-directory is purely a userspace construct. > > It doesn't have to be. It would be good to have the kernel > keep a bit more info about users, such as limits.
It could actually make sense to track that kind of info in the kernel for better fork-bomb and general D-of-S protection algs. (comments, anyone?)
> It wouldn't > hurt to have a daemon (like kerneld) feeding /etc/passwd info > to the kernel as requested.
Even better: this whole task is ideally suited for a user-space filesystem using the userfs package and the libc passwd/nis resolver.
> > This could be done with minimal code, default to "off", and be a > > useful, easy-to-tune mechanism for people who are more A.R. about > > their security. It would also keep policy _out_ of the kernel. > > Yep, you won't actually be using it. Policy does of course > go into the kernel since it must.
But it only goes in _when_ it must. The notions of usernames, home directories, etc don't _need_ to go into the kernel, so why _should_ they?
> What daemon is PID 1? Why?
(a) Red Herring, since the PID assignment algorithm should be irrelevant (i.e., opaque) to user code (except for threads, CLONE_PID anyone?)
(b) Fixing the PIDs of special processes with particular meaning to the kernel (init = parent of orphaned processes, swapper = obvious significance) actually _reduces_ kernel bloat by removing process-space searches, and prevents the need for a "special process registration" syscall, which would be superfluous.
> Who sets the permissions in /proc? Why?
This is a weakness, actually. Several patches have been floated allowing permissions in proc to be changed, and I've even seen some simple utils that can be used to make it persistent across reboots (It can be done with some fairly straightforward shutdown and boot scripts.) I hope this hits the mainstream, and soon.
> Arguments to keep policy out of the kernel are too often just > excuses to get rid of some feature that you don't personally > want to have.
It was also among the first concrete suggestions on the list of _how_ this feature, which there is apparently some desire for, could be implented _in_practice_ ("yeah, JimsOS does this..." isn't a suggestion, it's an editorial comment). I have no interest in blocking features. I like features.
I think this feature _would_be_ useful. I'm a big fan of doing everything reasonable to secure a multi-user system. I just don't see the point of implementing this particular security feature all-out inside the kernel, with a new support daemon and all that would go with it. My previous suggestion, for the minimal kernel hook, is more than adequate; but honestly, it makes more sense to just do it all in user-space with a userfs. (BTW, anyone know if it has been updated for 2.1.{new_vfs} yet?)
Some interesting question to consider, wherever this gets implemented:
Multiple usernames can be mapped to a single UID number. This is a non-issue if "personal tmp" directories are named by uid ("/tmpfs/501/"), but if they use usernames, should the tmpfs filename be mapped according the "first username with this UID" or to "which username is logged on to this tty"? What about by-group /tmpfs directories instead? (This can be useful for some kinds of communications, such as temporary named FIFOs, or for clustering debug/stderr logs together from administrative groups, e.g. "daemon-group") Which one gets used for uid's with multiple affiliated groups?
Still __Just__ __Suggestions__, Adam (who has no say on what does and doesn't get into the kernel in the end anyway, so don't get too worried about what I say... ;-) -- Things look so bad everywhere Adam D. Bradley artdodge@cs.bu.edu In this whole world what is fair Boston University Computer Science We walk blind and we try to see Ph.D. student and Linux hacker Falling behind in what could be ----> Bring me a Higher Love ----> <><
| |