Re: Conditional SymLinks

Tall cool one (
Fri, 19 Dec 1997 11:42:52 -0500

"Albert D. Cahalan" <> writes:
> Steve Baker writes:
> > You can at least do:
> >
> > /tmp -> /proc/self/env/HOME/tmp
> >
> > and expect it to work reasonably well, except in the cases where HOME
> > isn't defined, points to /, etc...
> >
> > I guess the only real way to do it would be the way my first proof of
> > concept worked, but cleaned up and expanded upon I suppose. It also means
> > that conditional sym-links haven't got a chance of getting in the kernel.
> The problem is that you used the normal process environment.
> You could use kernel variables and the init environment.

Kernel variables? I suppose you mean something along the lines of user
env vars, but located in the kernel. Set with a syscall like?

int setkvar(char *name, char *value, int flags);

where flags set inheritence and write protection. Null value attempts to
remove variable. "login" can be just another variable. This would let
/bin/login (or init or the kernel itself) set all manner of protected
variables, like tmp, home, ipaddr, coredumpdir, etc, which couldn't be
changed and always be there since they'd reside in the kernel. Such vars
could be usefull for more than just conditional sym-links.

That could require quite a bit of ram, which isn't swappable, but who
can't afford lots of ram these days? ;)

I still don't think a /proc interface would be as usefull as my first
conditional symlink patch idea. You need to be able to put more than one
variable in the same link and have default actions. You might even need to
override variables if they are not set correctly. I don't see how you could
do any of the above through a /proc fs like interface.

> The whole dentry system was originally created to support this,
> so something will get in the kernel. The original intent was
> to have an NFS server share the root partition with clients.
> That means /etc is the same, which is troublesome.

I know little about dentries, since I don't use 2.1 and haven't looked at
those structures, so perhaps you could explain to me how they would be
usefull for purposes of conditional sym-links.

> To redirect /tmp to home directories, I suggest we add
> the setlogin(2) system call like Digital Unix.

I don't see how that would help redirect /tmp directories. The home
directory could still be anywhere, unless you just want a /tmp/$USER/...

> int setlogin(char *name);
> setlogin(2) is restricted to root. It is called at login time.
> getlogin(2) is a system call too, so it can't be fooled.
> The login name is inherited by children. It does not change
> even when the UID changes, so "su" won't cause trouble.

I'd think in the case of "su -" I'd want su to "fool" the system. Kvar's
could have a protection levels where root can reset some variables, such as

> This would be the perfect opportunity to add per-user limits.
> The actual system call could take more parameters than the
> plain setlogin() call. This allows /proc/utmp too.

Per user limits? What sort of per-user limits? Those are (theoretically)
already set with setrlimit() yes?

/proc/utmp? Why?

- Steve

.------------------------------------------------. # * # # # # # #
| Steve Baker | Barely Working | # ## # # # # #
| | System Administrator | # # # # # # # #
| Red-Hat Rulz! | Will work for hardware | # # # ## # # # #
`-- SYS-ADMIN FOR HIRE, HAVE UNIX, WILL TRAVEL --' #### # # # ## # #