[systemd-devel] [PATCH] Pass environment over daemon-reexec

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Thu Feb 7 18:08:56 PST 2013

On Fri, Feb 08, 2013 at 01:36:26AM +0100, Lennart Poettering wrote:
> On Thu, 07.02.13 00:40, Oleksii Shevchuk (alxchk at gmail.com) wrote:
> > Fixes this bug:
> > alxchk > systemctl --user set-environment A=B
> > alxchk > systemctl --user show-environment | grep ^A=
> > A=B
> > alxchk > systemctl --user daemon-reexec
> > alxchk > systemctl --user show-environment | grep ^A=
> > alxchk >
> Looks good in principle, the only thing that concerns me a bit that if
> for some reasons the env block contains '\n' or so in one of the vars,
> things might get weird. We currently do not validate the env block we
> get passed in, and that's something we really should do (there's
> currently a bug open somewhere, where invalid UTF8 data in the env block
> passed in via the kernel cmdline might cause us to get kicked from the
> bus...)
> Now, I wonder if nelines in env vars is actually OK or not. It's
> definitely dangerous, but I am wondering if it is dangerous enough to
> prohibit it altogether in systemd (I am inclined to say that invalid
> UTF-8 data is dangerous enough, so I am happy to prohibit that...).
> So, humm, are environment vars allowed to include newlines? Should we
> filter them out? We need to do some research...
> If we have to filter newlines from the env block anyway, then this patch
> looks good and can go in unmodified. (Alternatively we could also escape
> the env vars here with cescape() or so, and cunespace() it on
> deserialization again).
Hi Oleksii,
I gave your patch a spin again today, after fixing the unrelated
uninitialized memory access, and it doesn't seem to do anything :(

$ systemctl --user set-environment A=A
$ systemctl --user show-environment |grep ^A
$ systemctl --user daemon-reexec
$ systemctl --user show-environment |grep ^A


More information about the systemd-devel mailing list