lkml.org 
[lkml]   [1997]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Conditional SymLinks

>>> There is I beleive some unix out there where one
>>> could imbed environment variables in symlinks, like:
>>>
>>> /tmp -> ${HOME}/tmp

That is Linux actually, with a patch for 2.0.xx kernels.
The variables are not in the environment though.

> 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 wouldn't
hurt to have a daemon (like kerneld) feeding /etc/passwd info
to the kernel as requested.

> /tmp (symlink) -> /proc/uidtmp
> /proc/uidtmp is an on-the-fly symlink (like /proc/self)
> to -> /realtmp/<euid> (or whichever UID field is apropos)
> (Where "realtmp" some directory name settable with a proc entry or
> sysctl). And the /realtmp/<uid> files can actually be whatever you
> like, e.g. individual symlinks to "/home/username/tmp/"

I don't believe you'd use that.

In any case, the transname patch would do something like:
/tmp -> /home/#FSUID#/tmp

Better yet,
/tmp -> /tmpfs/#FSUID#

> 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.
>
> Just an idea.

Yep, you won't actually be using it. Policy does of course
go into the kernel since it must. What daemon is PID 1? Why?
Who sets the permissions in /proc? Why?

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.

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.031 / U:36.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site