[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep.sh / env sanity patches

From: John Davidorff Pell
Subject: Re: GNUstep.sh / env sanity patches
Date: Tue, 17 Aug 2004 18:50:55 -0700

The OpenStep system was designed be a system, not a user environment. It included a really friggin' great user environment, but that user environment was built upon a system that we do not have.

By building GNUstep upon other, existing, systems, there arise issues which cannot be *correctly* solves (but that doesn't mean we can't find something almost correct).

I /really/ dislike having something like /etc/GNUsteprc.

If GNUstep-installation-one is installed in /usr/local/GNUstep1 and GNUstep-installation-two is installed in /usr/local/GNUstep2, then we need some way of telling one that its in one directory, and the other in the other, hence the need for a specifiable GNUsteprc, right? Actually, i would expect that installation one should have hard coded into it where it lives, since it cannot be easily relocated anyway. This should solve some of the requirements for a GNUsteprc.

I think that all such requirements can be fixed this way. If I want to run myTool with GNUstep2 instead of GNUstep1, then I should run /usr/local/GNUstep2/{System,Local,Network}/Tools/myTool anyway, right?

Running tools from, say, ~/Tools should also work correctly since LD_LIBRARY_PATH points to GNUstep2 instead of GNUstep1 and the libraries should know where they are anyway.

This would negate the need for /etc/GNUsteprc or any user-sourcable script, except of course to set LD_LIBRARY_PATH, which is the only one I can see that is needed. If a user is using GNUstep, they should be willing to set this or to source a (tiny) script to set this. When using openapp or opentool, why can't it set these variables??

Or we could require a more functional ld.so...

For developers, there would continue to need to be a GNUstep{rc,.sh} script to source, but this is something that I see no way at all to prevent.



Nicola Pero wrote:
The discussion is getting interesting, it's probably time to do something, we've got plenty of patches pending, even if I'd like to start again from

Shall we recap a little bit the state of the issue. :-)

We've inherited a system which was designed many years ago to support the
following --

 * support multiple concurrent separate installations at the same time,
and where switching from one to the other was very simple

 * support multiple runtimes, base, gui libraries, and where switching
from one the other was very simple

 * support multiple architectures with a fat layout

 * support multiple types of libraries (debug, profile, etc) with
automatic linking to the right one

* support dropping applications, tools, libraries, frameworks into each user's "domain" and have them immediately work without any reconfiguration

* have a *Step filesystem layout and organization separated from the rest
of the system ("better" than the rest of the system)

Now we have new design requirements (which were not given particular
importance in the original design), and which are generally conflicting
with the previous ones.  I mean, people would like a system which --

 * is a native system which follows the native filesystem organization

* works out of the box, natively, without requiring any setup (no startup
scripts etc)

Those people generally also don't need/use many of the "support multiple xxx" features, often they think those are confusing problems rather than

An additional requirement which often pops up is that the system should

 * allow each user to put one's user domain and user defaults in the
directory / location that they want.

Presumably the solution that we're going to architect will be flexible
enough to support both styles.  That might be quite a complex solution

Now there are some additional things to notice.

1. To support libraries and frameworks in the user domain, LD_LIBRARY_PATH
must be set each time the user logs in to include the user domain's
library folder in the linker path (you can't set the global paths in
ld.so.conf because every user needs different paths!).  This is in
conflict with the "no startup scripts" requirements.  The conclusion is
that if you source no startup scripts, you won't be able to put libraries and frameworks in the user domain. To be able to do so, you'll still need
to source a script.

2. To compile stuff using gnustep-make you will always need the
GNUSTEP_MAKEFILES environment variable set.  If we design the system
properly that might be all you need to do.  I'd like that.

Anyway, it looks like a reasonable architecture could be --

We have a system GNUsteprc file.  The format of the file should be such
that 1. it can be easily parsed by gnustep-base; 2. it can be included in
shell scripts and makefiles (including is the only real solution for
makefiles to get decent parsing speed). A text format with XXX=YYY lines, where XXX is some variable/name we choose, and YYY is what we want to set
it to (normally a path, but might be YES/NO too or something similar),
seems best.  It does fulfill those requirements.

The GNUsteprc is expected to be on a specific location which depends on
the platform (for example, /etc/GNUsteprc in linux).  Presumably the
hardcoded location of the file can be changed at config time.

This works very well for a single GNUstep installation on the machine.
If we want to support multiple installations though (even if as a special
case where you need to source scripts to do it) there must be a way to
override the file with another one -- to tell gnustep-base to use another

It would be nice to be able to pass the location of a different file:

 * on the command line as a special argument

 * as a shell variable

Then if you want to have multiple installations, you can have them in
different locations. You run scripts to change PATHs, LD_LIBRARY_PATHs,
etc switching from one to the other.  Then you can also set a shell
variable to tell tools to read a different GNUsteprc. That only applies to the crazy people who do those things with multiple installations (ehm,
I do, even if only for testing); for a single GNUstep installation (all
the rest of us including me when I'm not testing), there is a single
GNUsteprc file in /etc (on linux) and nothing else needs to be done -- no
shell variable needs to be set, nothing.

Unfortunately, tricky bits abund.  The GNUsteprc file will implicitly
specify, for example, where gnustep-base should look for basic files such
as character sets (if gnustep-base is installed in /usr/lib/ and the
character sets are installed in a totally different unix location which is
used for library resources, locating them can be non trivial as the
location might be totally unrelated to gnustep-base's shared object
location). Now if you have a suid tool compiled using gnustep-base, you
don't want the user running the tool to be able to tell gnustep-base to
load those files from another location other than the standard one,
otherwise they could load their own malicious stuff and have gnustep-base
running as root use it -- a potential attacking technique.

So maybe what we could do is that "delicate" tools could tell gnustep-base not to accept the special command line argument / shell variable to change
the GNUsteprc file to be read.  A function call performed just after
main() would tell gnustep-base to run in "howitzer" mode where it ignores requests to read GNUsteprc files other than the default /etc system one. So if you're writing a "delicate" system script (eg, anything suid), you
call that function and you're safe from those attacks.

If the GNUsteprc file is missing, gnustep-base would abort.  When
gnustep-make is installed, GNUsteprc would be installed as part of
gnustep-make, so this should never happen unless you're doing weird

The GNUsteprc file would contain stuff like --


(the reason we still prefix those with GNUSTEP_ is that the file *will* be
included in makefiles and shell scripts, where we want to stay in our
namespace).  I suppose any of those is optional but GNUSTEP_SYSTEM_ROOT
which is compulsory.

We'll also add optional stuff like


(better names to be determined of course) etc. Those needs to be
discussed, but the list should be quite easily produced by looking at what variables the makefiles use and what dirs are available in the *steppish
API.  Presumably GNUSTEP_SYSTEM_ROOT would not be much use if all those
are manually set to something else.

Would you be able to override those using shell variables ? No. There is no reason why you should be able to. If you want to change those, you use
a different GNUsteprc script and point gnustep-base to it.

Of course if you're using makefiles and shell scripts it might still work if you manually override those before using them, but that's not supposed
to be supported (/work).

Now if you add manually your tools/library paths to PATH / ld.so.conf then that should be it. You don't need to do anything else. Even better, if
you are setting GNUSTEP_SYSTEM_LIBRARY_DIR and similar to the native
system paths, this might not be needed at all.  Everything should just

If you want to have the same functionality that we have at the moment, you
would make a tradional *Steppish installation of GNUstep in its own
separate filesystem, then you'd source GNUstep.sh.  GNUstep.sh would
actually no longer contain hardcoded paths, but would include
/etc/GNUsteprc (optionally I suppose GNUstep.sh could accept a GNUsteprc
file location as an argument) to get the paths, then use those to set
paths, library paths, classpaths, etc. When the time comes it will be my pleasure to rewrite all that shell/makefile machinery to do this, so don't worry too much about this -- as soon as the format is such that the file
can easily be included, we'll have shell/makefile machinery use it.

You might still need to source GNUstep.sh -- for example if you want to
install libraries / frameworks in your own user domain, even if you are
not interested in multiple installations.  I do like that.

The final issue is how users can customize the location of their user
domain path / user defaults database (important, as usual, gnustep-base
when running as the superuser should be able to determine the location of the user defaults of another user as that's required to implement the API
which lets the superuser touch defaults of other users).

Each user could have his own GNUsteprc, which would need to be the file
~/.GNUsteprc. Of course again a system of command line switches / shell
variables could allow users to change this to another file; again suid
tools (or just "delicate" tools) could be compiled to ignore requests to
read another file.

The ~/.GNUsteprc file should contain only the location of
GNUSTEP_USER_ROOT and of the GNUSTEP_DEFAULTS.  gnustep-base can ignore
anything else in the file; shell scripts and makefiles will just stupidly
include the whole file, meaning the user could set a different
GNUSTEP_SYSTEM_ROOT in it but that's the user's problem, things just won't
work, it's not a security risk, we have no suid shell scripts or such.

Probably if the sysadmin wants to recommend a standard location for the
user domain path / user defaults database, the system GNUsteprc could
contain something like


Presumably if that's included in a shell script or in a makefile it should
work no matter which user is including it because it's using ~ for the
user home directory.  The user's .GNUsteprc file is included after the
system one, so a user should be able to override GNUSTEP_USER_ROOT with
whatever they want.

The current option to be able to FORCE some choice of USER_ROOT or
DEFAULTS_ROOT for all users would be dropped. I don't believe it has any real use, if there is something we have to drop to square the circle and make the system flexible but reasonably understandable, the FORCE options
are the best candidates.

If you are running a tool for a user with no directory but you still want defaults to be written somewhere, you could pass on the command line the
argument to specify a special user .GNUsteprc, gnustep-base would read
that, and use it to locate the defaults on the filesystem wherever you
want to put them.

make_services would no longer be necessarily run automatically, since you no longer source GNUstep.sh. It shouldn't be there in GNUstep.sh anyway,
but we have to decide where/if it should be.

It would be good to limit the usage of gnustep tools in makefiles; except where explicitly required (you can't build autogsdoc documentation without running autogsdoc) we shouldn't be running any gnustep tool. If a tool is
required by the makefiles, it should be a C tool included with
gnustep-make.  I don't think that should be a problem except for
make_services itself, which is only run in test mode anyway, hmmm,
probably that should be replaced with some sort of shell check, hmmm stuff

This is all an initial draft generated by mixing up comments, suggestions,
ideas, patches from a lot of people, so feel free to comment on it --
we'll let people discuss quite a bit before taking any actual decision --
but I'd really like to implement it in the next few weeks.  Anything I
missed in this description (there is always that last difficult missing
detail) ?  Special comments ?

Please excuse me if I'll not answer quickly or if I stay out of long
threads -- keep banging and suggesting anyway

Thanks to all

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]