On Thu, 07.02.13 00:40, Oleksii Shevchuk (alx...@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). Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
