Re: env: can it be used to let only certain variables through (if they're set)?

[Pádraig Brady]

On 21/01/2022 15:16, Christoph Anton Mitterer wrote:
> On Fri, 2022-01-21 at 14:33 +0000, Pádraig Brady wrote:
> > > On the command line (i.e. without shebang) I can do:
> > >
> > > /usr/bin/env -i ${LC_MESSAGES+"LC_MESSAGES=${LC_MESSAGES}"} command
> > > args
>
> btw: I should probably add, that even this on the command line is not
> really a 100% solution.
>
> The problem is, that in the above, LC_MESSAGES would always (when set)
> be added to the command's environment - whether or not it was exported.
>
> And I don't think there is a good/portable way to get that done.

Good point

> > The standard shell syntax to support
> > setting a variable iff it's not previously set is:
>
> But I only want to set it if it *was* previously set (and exported to
> env)?!
>
> That would be more like ${var:+...} wouldn't it?

Right, I was just trying to go though all possibilities

> > So expanding your example this would be:
> >     ${LC_MESSAGES=${LC_MESSAGES}}
>
>
> >     Quite verbose as you would probably want to list many of these on
> > the -S line
>
> Well kinda... I mean the whole idea is to sanitise the environment by
> letting only such variables through (if set at all and exported) that
> I'd consider "save" for the script in question... and perhaps
> statically overwriting some others.
>
> Something like:
>
> env -i 'PATH=/set/this/always' '${FOO+if-set-set-static-value}' 
> '${LC_ALL+${LC_ALL}}'
>
>
> Constructs like this might probably go too far:
> env -i '${PATH+${PATH}${JAVA_HOME+:${JAVA_HOME}/bin}}'
>
> i.e. if PATH is set, set it to $PATH and if JAVA_HOME is set to,
> further append :$JAVA_HOME/bin .

Another thing to consider for including everything on a shebang line
is system limits (127 bytes on linux for example)

> > Another possibility to implement this functionality
> > while avoiding all of the above disadvantages
> > would be to augment the recently proposed --file option
> > to also support removing, or passing if set functionality
>
> Hmm sounds rather ugly for my purpose? It would require a sidecar file
> for every such script, wouldn't it? And also adding further unnecessary
> stats and the like.
>
> Even sounds like something that is rather delicate in terms of
> security.
> Consider a script that's started with such file, but the file is not
> actually existing.
> An attacker is somehow able to create the file and add things like
> LD_PRELOAD_LIBRARY to it.

Well yes the "sidecar" or "defaults" type file
would need the same protections as the script itself.

> > Another possibility might be to support a POSIX shell compat syntax
> > for this?
>
> Well, given that you already support ${} style on the command line,
> that would have seemed the most natural syntax for any extension there.
> And wouldn't it be compatible, because now we'd have some :+ in it,
> which before wasn't valid?
>
> Or do you think because someone could have done
> env ${VAR}=foo
> in which
> the literal '${VAR}' would have been the env var name?

Sorry for being unclear.
I was only talking about the separate file syntax in this context.

cheers,
Pádraig