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.
> 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?
> 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 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.
> 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?
Cheers,
Chris.
