[Xquartz-dev] 2.3.2_rc4

[Cameron Simpson]

On 27Dec2008 09:43, Harald Hanche-Olsen <hanche at math.ntnu.no> wrote:
| + Cameron Simpson <cs at zip.com.au>:
| > #!/bin/bash -ue
| > [...]
| > haveenv=
| > 
| > usage="Usage: $cmd {--have-login-env | command [args...]|"
| > 
| > if [ $# -gt 0 ] && [ "x$1" = x--have-login-env ]
| > then
| >   haveenv=1
| >   shift
| > fi
| > [...]
| > if [ $haveenv ]
| > then
| >   eval "set -- $_WITH_LOGIN_ENV_QUOTED_COMMAND"
| >   unset _WITH_LOGIN_ENV_QUOTED_COMMAND
| >   exec "$@"
| > fi
| 
| Would it make sense to drop the --have-login-env command line flag and
| just test for the presence of _WITH_LOGIN_ENV_QUOTED_COMMAND in the
| environment instead? I think we can ignore the possibility of an empty
| value, so a test like  if [ -n "${_WITH_LOGIN_ENV_QUOTED_COMMAND:-}" ]
| replacing  if [ $haveenv ]  would do. Suggested patch attached.

It could be done, but what does it do for us? I can't see that it solves
any specific problem.

I also think I'm unhappy about just evalling an environment string
without an overt instruction (i.e. the --have-login-env option).

Your change does simplify the script a bit, but commits the script to
blindly trusting the calling environment. The command line option means
we have greater confidence that the envvar was made by the script and
is fit for purpose.

It's not really a security thing (there's no privilege change here) but more
a reliablility robustness thing.

So, can you explain what this change gains for us?

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/