Re: Conditional SymLinks

Adam D. Bradley (
Fri, 12 Dec 1997 13:22:19 -0500 (EST)


> > 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,

> 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_

> 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

(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__,
(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
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  ---->  <><