Re: Feature request: setting env vars for binary wrappers

[Ralf Wildenhues]

[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]

Hi Behdad, everyone,

Sorry for the delay again.

* Behdad Esfahbod wrote on Thu, Mar 09, 2006 at 04:59:38PM CET:
> On Wed, 1 Mar 2006, Ralf Wildenhues wrote:
> > * Behdad Esfahbod wrote on Wed, Mar 01, 2006 at 05:15:17AM CET:
> > >
> > > This is a feature request for libtool.  Let me describe the
> > > problem as I face it, so you may have a workaround for it
> > > already:  I'm using libtool in the Pango text rendering engine.
> > > The Pango library accesses a file in $prefix/etc/pango/pangorc to
> > > find its modules at run-time.  Now all I want to do is to be able
> > > to run the examples in pango/example when Pango is not installed.
> > >
> > > The easiest way that can be done is to set the PANGO_RC_PATH
> > > envvar to a special pangorc file.  Another is to pass the
> > > --pangorc path-to-pango-rc to the examples if they understand it.
> > > What I need from libtool is to let me do one of these things in
> > > the wrapper it creates for uninstalled binaries.

[ my concerns were: we don't always build a wrapper ATM. ]

> > If we can find an answer to this question to define coherent semantics,
> > I'm all for it.

> Ok, this is my view of the problem:  Running uninstalled programs
> requires some modifications to the environment.  One is to make
> sure that the uninstalled libraries are linked.  Other changes
> may be needed, on a per application basis.  Libtool is free to
> choose how to implement these.  So far it has only supported the
> library path modification, and implemented that using a wrapper
> script on some platforms, or using rpath on others (right?)

More or less, yes.

> The same goes with the other modifications.  They can be easily
> implemented using a wrapper.  So if there are such modifications
> requested, a wrapper should be used.

Yep.  And that's really the easiest solution: as soon as extra arguments
or extra environment variables are passed, we always build a wrapper.

> My current workaround has been making pango-view accept a
> --pangorc path-to-pangorc parameter and defaulting to ./pangorc.
> But that opens up a known security problem...  So I really want
> to "fix" it the right way.

I don't quite understand how this fixes any security problems...
but here you go with a suggestion (against current CVS HEAD).


The attached patch implements two new link flags, -wrapper-arg and
-wrapper-env, to prepend arguments to programs, and modify their
environment.  They will force creating a (shell) wrapper.

Here's the hairy part about it: somebody may eventually want to extend
the C wrapper that is currently used on w32 to encompass all the
functionality that the shell wrapper currently has.  And while I don't
have current plans about this, I still don't want to add any
unnecessary obstackles to it.

So whatever we add to the shell wrapper should be doable easily in a C
wrapper as well.  This led me to add these restrictions:  the
-wrapper-env works like putenv: you pass an argument `var=value', the
variable will be exported, the value will _not_ be interpreted by the
shell any more.  For now you cannot unset variables (this is to cater
for hosts with a shell that does not support `unset'), and, e.g.,
  -wrapper-env 'foo=$bar'

will cause the environment variable `foo' to contain the four characters
$, b, a, and r, not the contents of the variable $bar.

Similarly, -wrapper-arg will add exactly one literal argument to the
exec.  I've put suitable quoting in place for this to work with most
kinds of input, and of course a test to this end.

What do you think?  OK for HEAD right now, or do you think this is too
intrusive now?

I think we should not backport this to 1.5.x, it is a new feature.

Cheers,
Ralf

env-wrapper3.diff
Description: Text document