User: Password:
|
|
Subscribe / Log in / New account

Systemd programming part 1: modularity and configuration

Systemd programming part 1: modularity and configuration

Posted Mar 16, 2014 10:10 UTC (Sun) by g1pi (guest, #95996)
Parent article: Systemd programming part 1: modularity and configuration

"The first is to modify all the daemons to accept any command line configuration also from environment variables."

In my opinion, this is going to cause lots of headaches to sysadms and users of all distributions. Currently a glance at the output of "ps -elf" tells everybody (even non-privileged users) how the daemon is configured at runtime.

If configuration migrates into environment, only privileged users can examine it. Imagine a dumb sysadm reports a problem and before you can help him, you have to explain how to dump the environment of a running process, and then try to guess why the environment differs from the one he (or you) expected.


(Log in to post comments)

Systemd programming part 1: modularity and configuration

Posted Mar 16, 2014 12:06 UTC (Sun) by khim (subscriber, #9252) [Link]

Currently a glance at the output of "ps -elf" tells everybody (even non-privileged users) how the daemon is configured at runtime.

And with environment variables you can get the same info with “ps axel” (again, even non-privileged users can do that). Is it such a big difference?

Systemd programming part 1: modularity and configuration

Posted Mar 16, 2014 19:59 UTC (Sun) by g1pi (guest, #95996) [Link]

On my linux system (rel. 3.2) an unprivileged user cannot read the environment of other users' processes, either via "ps axel" or directly.

Don't know if that depends on some sysctl variable, but I always get an -EACCESS (permission denied) whenever I try "cat /proc/X/environ" (for X not a process of mine).

Systemd programming part 1: modularity and configuration

Posted Mar 16, 2014 12:11 UTC (Sun) by khim (subscriber, #9252) [Link]

Imagine a dumb sysadm reports a problem and before you can help him, you have to explain how to dump the environment of a running process, and then try to guess why the environment differs from the one he (or you) expected.

This is already needed (things like LANG or LC_ALL can effect daemons in funny way). Thankfully with systemd it's easier to trace since it cleans up environment by default (while sysvinit scripts don't do that and distribution-specific helpers do that in not-entirely-consistent-way).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds