_dbus_shell_parse_argv

[Simon McVittie]

On Fri, 26 May 2017 at 18:45:06 +1200, Lawrence D'Oliveiro wrote:
> On Thu, 25 May 2017 22:44:28 -0700, Thiago Macieira wrote:
> 
> > It's not crippling if it does exactly what was wanted.
> 
> Wanted by whom? It can be easily bypassed by, for example, a line
> 
>     Exec=/bin/sh -c '«command»'
> 
> in a .service file.

Yes. If, as a service author, you want your D-Bus service to be implemented
in POSIX sh (or more realistically, wrap a shell script around a service
implemented in some other language), and you are happy with it being only
as portable as the shell features you use, you can either write it in
the style you describe or as a #!/bin/sh script.
This is the same arrangement as Exec= in freedesktop.org .desktop files.
If you do this, you'll probably want the last command in your shell script
to use the exec builtin ("exec /usr/libexec/myservice").

That way, your dependency on POSIX sh is between you and your users, and
is not something that dbus-daemon is forcing on you.

A common reason to avoid using a shell is concerns about the security
of interpolating user-supplied, potentially-untrusted arguments into
a shell script. I don't think this one actually applies to D-Bus,
but not using a shell makes us consistent with .desktop files, where
argument interpolation for special tokens like %f *is* a concern.

systemd has similar restrictions on ExecStart= etc., even though systemd
is specifically not portable beyond GNU/Linux and only accepts trusted
input, so that it can avoid the CPU and memory overhead of invoking a
shell in the simple cases (in practice that's something like 95% of
them). Just like D-Bus, it does not prevent you from wrapping a shell
script or a sh -c one-liner around your service if you need one; but
by not doing that itself, it gives you the option of having faster
startup by not going via a shell, which in practice is often sufficient.

Another reason to not use a shell is that if we ever wanted to switch
from shell to simple command evaluation (for example to make it feasible
to run D-Bus services on Windows), that would be an incompatible
change (previously-valid services would become invalid). We aim to
design D-Bus (and its reference implementation) to make it as
straightforward as possible to not break compatibility.

If we always used /bin/sh, we would effectively be making POSIX sh
part of the D-Bus Specification, and we would be privileging one
programming language (or "scripting language" if you prefer to make
that distinction) above all the others. If I had to choose one
programming language to advocate over all others, I'm not sure what
it would be, but it would certainly not be sh.

> I thought Free Software was about giving people choices, not taking
> them away.

Firstly, by not requiring /bin/sh we *are* giving people choices:
they can choose to compile the majority of D-Bus-using software
on deficient platforms (where /bin/sh is non-POSIX or doesn't exist)
and have it still work without modification, if they want to.

Secondly, you have many choices around your use of Free Software, but
exercising some of those choices would require forking projects whose
maintainers' choices do not match yours. A project that aims to be
all things to all people involves an unbounded amount of work, and
if we want to achieve our goals, we need those goals to be finite.
(Vaguely relevant reading: <http://islinuxaboutchoice.com/>)

    S