[Top][All Lists]

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

Re: GNUstep.sh / env sanity patches

From: Nicola Pero
Subject: Re: GNUstep.sh / env sanity patches
Date: Tue, 17 Aug 2004 19:14:10 +0100 (BST)

> Hrm, not one response.
> ... I guess that mean everyone just LOVES these patches, eh? ;-)
> I realize the entire GNUstep.sh related issue is quite sensitive for 
> some people, but these patches don't/shouldn't alter current behavior.

Sorry, I was on holidays.

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

reply via email to

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