[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] Add systemd socket launching support

From: Eli Zaretskii
Subject: Re: [PATCH v3] Add systemd socket launching support
Date: Fri, 01 Apr 2016 10:10:34 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Thu, 31 Mar 2016 17:22:35 -0400
> >> In other similar functionality I've seen over the years, an alternative
> >> was to pass the fd as an additional argument on the command line, but in
> >> any case whether it's received from the environment or the command line,
> >> the file-descriptor to use will just be an integer, and it's already
> >> exposed to Lisp.
> > It's an attack vector expecting to happen, so we should try to avoid
> > that.
> I'm not sure what kind of attack you're thinking about.

I'm not sure myself, but I'm not a criminal, so don't ask me about the
details.  I just know that exposing a handle through which someone can
feed Emacs any commands they want is a bad idea.

> And I'm not sure how the latest patch would address it (you can
> still cause Emacs to use an arbitrary FD by providing the
> corresponding envvars).

That'd require a more serious breach of the system's security.

And anyway, that's not our problem, that's the systemd problem.  If
they don't protect their sockets against such attacks, they should get
their act together and do it.  And users should be aware of such
problems with systemd, and refrain from configuring Emacs to use it,
IF such problems indeed exist (I don't know if they do).

But what happens inside Emacs is _our_ responsibility.

> >> AFAICT, only the first part is systemd-specific, so I think it would
> >> make sense to try and avoid having systemd-specific details leak to the
> >> other parts.
> > I agree, and the last version of the patch already does that: it only
> > requires a boolean flag exposed to other APIs.
> But the process part of the patch could theoretically be used in other
> contexts, fundamentally, whereas it ends up being tied to systemd, so
> although it's code that can be compiled and could work regardless of
> systemd, it ends up being systemd-specific since it only works when used
> in the systemd-way and only if you linked with the systemd library.

Do you know about any other Free software that offers similar
services?  If you do, by all means let's design an interface to be
less specific to one of them.  But if no such alternative exists, I'd
rather have something with as small a signature as possible, and worry
about extending that when we have a real contender.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]