Isaac Dunham <ibid...@gmail.com> writes:
> On Thu, Aug 06, 2015 at 05:14:28PM +0200, Laurent Bercot wrote:
>> On 06/08/2015 16:31, Isaac Dunham wrote:
>> >If differences in environment can cause problems, it's a problem with
>> >design. A program that changes what it does just due to differences
>> >between the init environment and a login environment is going to be
>> >hard to debug.
>>
>> There are tons of those, and you can't fix them all. Stupid example:
>> less. Behaves differently when its stdout is a terminal and when it's
>> not.
>> The only way to ensure reproducible behaviour for a program, no matter
>> what it is, is to start it in a reproducible environment.
>
> Which, fortunately, is pretty easy to do: I wrote an environment
> sanitizer yesterday, because I was curious how easily solved that is.
> Usage is
> cautenv [-c DIR] [-u] [-x] COMMAND [COMMAND_ARGS...]
>
> and it cleans the environment (saving some user variables if -u is
> specified and DISPLAY/XAUTH if -x is specified), closes all fds above 2,
> changes directory to DIR ("/" if that's not specified, and calls
> execvp(argv[optind], argv+optind).
>
> It comes out at 123 lines, and could probably be made shorter.
It could be split into three tools: One which changes the environment,
one which changes to a certain directory and one which 'sanitizes' the
set of inherited file descriptors.
Presently, I have a tool which combines the last task with creating a
properly backgrounded process because file descriptor leaks really only
matter if the descriptor is leaked to a long-running process and because
that's a somewhat dubious safeguard: File descriptors should be managed
by the programs creating them and closing them on the presumption that
this program surely didn't bother is a practical necessity but not
theoretically sound.
I don't have anything for changing the environment but in general, the
same concerns apply to that: An environment variable was created in
order to communicate certain information to other processes and it
shouldn't be thrown away blindly. As a practical example, one of the
things I'm dealing with is a tiny distributed system for creating
certificates for VPN servers based on a (a number of, actually) OpenSSL
based 'CA installations'. This uses ssh combined with keys as secure
transport and since there's a setuid-0 program involved which talks to
the network, it originally just did a
environ = NULL;
This caused (minor) problems later on because OpenSSL didn't know where
to put its .rnd file and in order to get around these, I had to create
the missing environment variables with sensible values.
And this is the really sensible solution to this problem: If a program
supposed to run from a non-interactive environment needs certain
environment variables with 'correct' values, whatever starts the program
has to create these (or overwrite them in case they're already set). The
only useful task of the environment sanitizer is that it force Joe
Someone to fix the startup code because relying on another program
having set that up correctly won't work anymore.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
