Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: A challenge to all true hackers: objects and types
Message-ID: <1993Apr7.214626.1196@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C4FEo2.8no@sugar.neosoft.com> <1993Mar27.081223.2547@fcom.cc.utah.edu> <1p7mq0$fot@umd5.umd.edu>
Date: Wed, 7 Apr 93 21:46:26 GMT
Lines: 72
In article <1p7mq0$fot@umd5.umd.edu> mark@roissy.umd.edu (Mark Sienkiewicz) writes:
>In article <1993Mar27.081223.2547@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>>In article <C4FEo2.8no@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes:
>>>I think that's a reasonable conclusion. How about variant links using
>>>some other set of per-process/per-uid symbolic name space?
>>
>>As I pointed out in the previous post, this is based on the bad assumption
>>that a process may modify it's own environment or that of it's parent, both
>>of which are not allowed.
>
>Shells need to modify their own environment, or else this unfortunate example
>will come true:
>
> % mkdir foo
> % echo hello > foo/xxx
> % ln -s '$XXX/xxx' thefile
> % setenv XXX foo
> % cat thefile "cat" opens the file
> hello
> % cat < thefile "csh" opens the file
> cat: cannot open thefile: No such file or directory
Not true! The "cat" program is a child process that does the open when used
"correctly", and child processes can inherit changes to the environment.
The only place this would be a potential issue would be shell built-ins
which reference file system objects or shell opens of supposedly variant
objects whose variant parts aren't defined (your example here). If this
is a real issue (I don't think it is), then we can mandate a process being
able to change it's real environment by hanging it off the proc or user
struct (effectivel Peter's suggestion that environments and process local
logical names share the same space).
I don't think this is an issue; it's certainly not one if execle() is
used, as is generally the case for shells creating child processes to allow
them to provide their environment plus any changes to a child. Shells
not doing this can be modified (if there are any).
The shell is modifying the environment of the cat program which then does
the open.
The question is whether the actual expanded environment is stored in memory
following contiguously after the real environment from the parent. If not
(and I believe it is not), then the example will fail because the environment
is not stored at a known location within the process image any longer. This
is essential if environment variables are to be expanded, since the lookup
must take place in kernel space in the VFS layer.
Does this mean it's time to move the environment out of user space? This
will weigh heavily on the implementation of execle()'s passing of a modified
environment, but will also tend to buy us better control over things like
putenv on processes other than ourselves and the current limits on the size
an environment can grow to in a particular process.
Either way, the limit must be imposed that the process have the environment
it want's considered for variant link translation in a location where the
kernel can get at it and basically knows where it lives at all times. If
the translation of variant links is to include "putenv"'ed information as
well, the "putenv"'ed data must also follow the rules.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------