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/...
deal.
> 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
login.
> 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 | # ## # # # # #
| ice@mama.indstate.edu | System Administrator | # # # # # # # #
| Red-Hat Rulz! | Will work for hardware | # # # ## # # # #
`-- SYS-ADMIN FOR HIRE, HAVE UNIX, WILL TRAVEL --' #### # # # ## # #