Re: Feature request: setting env vars for binary wrappers

[Behdad Esfahbod]

On Tue, 2006-06-13 at 17:00 -0400, Ralf Wildenhues wrote:
> [ 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,

Hi again,

> Sorry for the delay again.

So, yeah, replying after two years... I know.  Hope you still remember
this issue and the patch is not too stale by now...


> * 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. ]

Sure, a wrapper is created if need be.  And this feature can be just
another reason to create a wrapper.

> > > 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.

Fair enough.


> 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.

But make variables are expanded, right?

> 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?

Sounds good to me.  Can it finally go in?!

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

Cheers,
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759