Re: Proposal question.

[Pascal Bourguignon]

> Date: Thu, 9 May 2002 23:48:19 +0100 (BST)
> From: Nicola Pero <nicola@brainstorm.co.uk>
> 
> 
> > > > > The general idea is that that is done via unix-like
> > > > > configuration files, basically a very simple ~/.GNUsteprc.
> > > > 
> > > > What's wrong with:
> > > > 
> > > >        . /usr/local/GNUstep/System/Makefiles/GNUstep.sh
> > > >        export GNUSTEP_USER_ROOT=$HOME/GNU-I-prefer-it-named-such-STEP 
> > > 
> > > Good question :-) - it's technical and I suppose there must already be a
> > > long thread archived about that somewhere.
> > > 
> > > I'm likely not good at explaining that - anyway, basically, to support
> > > properly the API and programs changing user, gnustep-base needs to be able
> > > to determine the gnustep user root dir of a generic user (particularly, of
> > > a user which is not the user the library originally started as).
> > > 
> > > If the generic user customizes his own gnustep user root dir by setting a
> > > shell variable in his ~/.bashrc or ~/.profile ... there is no way we can
> > > get it from inside gnustep-base running originally for another user.
> > > 
> > > Setting it inside a ~/.GNUsteprc solves the problem.
> > > 
> > > It's not particularly more complicated than setting GNUSTEP_USER_ROOT ...
> > > actually maybe even easier - and likely much easier to be changed/setup in
> > > a reliable but automatical way by software.
> > 
> > May be I should object to such programs, then.
> 
> It is a common behaviours for servers to start as root, then soon
> afterwards switch to a different user (eg, apache is normally doing that).
> 
> These servers start as root, but when they switch to a different user,
> they can no longer access/read/write root's gnustep user root and root's
> gnustep defaults.
> 
> What gnustep user root should they be using then ?
> 
> What gnustep user defaults ?
> 
> They can't be using the old ones, since they can't even access it.  They
> need ones.  They should be able to run properly as proper processes for
> the new user - which includes accessing user defaults for the new user,
> and includes accessing GNUSTEP_USER_ROOT of the new user, which is often
> used to store any sort of user-specific data and information.
 
It  seems to  me that's  another  kind of  problem we  have here.   In
general,  how can  GNUSTEP_USER_ROOT  be  changed on  the  fly, for  a
running application ?

By the same  token as programs such as apache,  login, sshd, etc, have
to  do  something  special  when  they change  their  (E)UID,  GNUstep
(server) programs will have to  do themselves.  I don't think that the
GNUstep library can do anything general here.

The point is, what happens  if after the initialization of GNUstep and
NSApplication, the program does a:

     setenv("GNUSTEP_USER_ROOT","/new/place/for/gnustep/user/root",1);

?

What you're asking is twofold:

   - a way for a program to change GNUSTEP_USER_ROOT on the fly,

   - a  way for  a given  program  to know  what GNUSTEP_USER_ROOT  it
     should use at a given time.

I don't know for the first question how GNUstep would behave.

For the second question, it's answered classically as:
    
    - inheriting the environment variable for normal programs,

    - using some other configuration information for special programs.

A  server  such  as  apache (GNUnavut?   GNUuchannulth?   GNUnakauyak?
GNUlato? GNUiqsut?  GNUchatlaht? GNUrvik? GNUksack?  GNUaitch? GNUtok?
(*)) would obvioulsy need a configuration file specifying the user and
group  under  which  it  should  run,  along  with  paths  to  various
directory,  and other  environment  data.   This is  the  place for  a
GNUSTEP_USER_ROOT specification, be it explicit or not.

(*) Sorry, I just googled some native nation names... ;-)


login, sshd,  et al.  don't do  anything, they just exec  a shell that
takes on it to interpret some  user configuration rc files to load the
environment.


For now, in my server programs written in GNUstep, I use a rc file such as:
...
case "$1" in
  start)
        echo -n "Starting ftd: "
        touch /var/lock/subsys/ftd
    export TZ=/usr/share/zoneinfo/Europe/Paris
    . /local/GNUstep/Makefiles/GNUstep.sh
        daemon /usr/sbin/ftd  # <-- headless GNUstep daemon.
        echo
    ;;
...

It runs  always under root, but if  it needed to change  UID, it would
need a  "HOME" and therefore  a "GNUSTEP_USER_ROOT" configured  in its
configuration    file,   if    GNUstep   code    would    accept   the
setenv("GNUSTEP_USER_ROOT", ...).



> > Do you realize  that a given user may  have several GNUSTEP_USER_ROOT,
> > and that his .profile may select automatically one or the other (along
> > with  different GNUSTEP_SYSTEM_ROOT and  GNUSTEP_LOCAL_ROOT) depending
> > on various circumstances.  The simpliest  of which may be a NFS-shared
> > home   directory   mounted   on   various   systems   with   different
> > architectures.
> 
> Hmmm - very interesting example - thanks ... hmmm.
> 
> Maybe we should extend .GNUsteprc to support multiple sections for
> multiple machines, or perhaps have the option of having .GNUsteprc-host
> files which would be used in preference to .GNUsteprc (if the hostname
> matches the matchine we are running on).  That would allow the user to
> decide if he wants the same gnustep user root and gnustep user defaults on
> all machines or to have a different one on some special machine.
> 
> If you (/someone) have a more brilliant idea, suggestions are welcome.

The  Workspace Manager  did  store screen  size dependent  preferences
(organization of  the dock for  example) in defaults depending  on the
screen size.  IIRC, WindowMaker does the same too. Similar care should
be  taken by  the  applications,  to handle  default  arrays when  the
default values may  depend on the current running  system. They should
be aware that a home  directory may be shared accros several different
configurations.

But  this, it's  when  GNUstep is  already  launched, initialized  and
already has its GNUSTEP_USER_ROOT.

My point is that the selection of the environment does not necessarily
depend only on the host.  It  may depend on a range of parameters that
we  can  hardly   consider  in  advance  to  put   in  a  hypothetical
'.GNUsteprc'.

As an exemple, my various  .bashrc, .emacs, etc, take into account the
host, the X display, its size, with some hairy conditions.


> > Please, tell me what can of action these programs would do?  
> > 
> > Why can't they work only on GNUSTEP_SYSTEM_ROOT and GNUSTEP_LOCAL_ROOT?
> > 
> > What good reason may have them to mess with one user's environment?
> 
> The same reasons any other program can have to read/write the user's
> environment.  It's normal for any program to read/write the user's
> environment.
> 
> 


-- 
__Pascal_Bourguignon__             (o_ Software patents are endangering
() ASCII ribbon against html email //\ the computer industry all around
/\ and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`; http://petition.eurolinux.org/

You're a web designer?   Please read http://www.useit.com/alertbox/ !

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------