systemd: Is it wrong?

JB jb.1234abcd at gmail.com
Fri Jul 8 14:06:10 UTC 2011


Jóhann B. Guðmundsson <johannbg <at> gmail.com> writes:

> 
> On 07/08/2011 12:41 PM, JB wrote:
> > Johann,
> > I think you are "fixing" it to work according to your world view 
> >
> 
> Nope
> 
> > $ man sysctl
> > ...
> > SYNOPSIS
> > ...
> >         sysctl [-n] [-e] [-q] -w variable=value ...
> > ...
> >
> > So, if nfslock.service file contains:
> > ...
> > ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
> > ...
> >
> > then this is the correct syntax.
> >
> > If this does not work as processed by systemd, then that means a bug ...
> 
> Or more likely this means that the content of the $LOCKD_TCPPORT 
> variable is not being delivered to /sbin/sysctl -w fs.nfs.nlm_tcpport=
> Like for instance if he left it hashed out in the sysconfig file the 
> service would fail since  fs.nfs.nlm_tcpport= is expecting to have some 
> value
> as I explained on the bug report in comment 43
> ...

Johann,

we know that.

But the fact is that you do not understand how the systemd program should
work.

The nfslock.service file contains this:
EnvironmentFile=-/etc/sysconfig/nfsservices

Let's assume that LOCKD_TCPPORT  is hashed out.

That means, in bash, you get "unset variable" value:
# echo $LOCKD_TCPPORT

#

Then this entry:
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
is formatted as follows after substitution:
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=

That's why you get, when executing manually in bash, this:
# /sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
error: Malformed setting "fs.nfs.nlm_tcpport="

This entry is passed to systemd for execution, as is !
It is the responsibility of systemd to parse it, determine what entry it is
(you could put in there any garbage, perhaps a virus, rootkit, etc), then if
a valid executable entry then it should validate its syntax and arguments
(are you still here, Johann ... ?!), and if not valid the entry should not be
executed, that is aborted or error completion code returned to calling env.

So, it is a systemd bug if it does not work ...

Btw, if you are able to pass your "version" of this entry to systemd's
execution environment and it is taken despite a violation of sysctl syntax
and programming security, then Gold help us :-)

JB




More information about the devel mailing list