unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: matthew@mattleach.net, emacs-devel@gnu.org
Subject: Re: [PATCH v3] Add systemd socket launching support
Date: Fri, 01 Apr 2016 10:10:34 +0300	[thread overview]
Message-ID: <83pou9u7md.fsf@gnu.org> (raw)
In-Reply-To: <jwvvb424a71.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Thu, 31 Mar 2016 17:22:35 -0400)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: matthew@mattleach.net,  emacs-devel@gnu.org
> 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	other threads:[~2016-04-01  7:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 20:53 [PATCH v3] Add systemd socket launching support Matthew Leach
2016-03-31 12:55 ` Stefan Monnier
2016-03-31 13:31   ` Matthew Leach
2016-03-31 17:11     ` Stefan Monnier
2016-03-31 17:38       ` Matthew Leach
2016-03-31 17:41       ` Eli Zaretskii
2016-03-31 18:14         ` Stefan Monnier
2016-03-31 19:27           ` Matthew Leach
2016-03-31 19:32             ` Matthew Leach
2016-03-31 19:34           ` Eli Zaretskii
2016-03-31 21:22             ` Stefan Monnier
2016-04-01  7:10               ` Eli Zaretskii [this message]
2016-04-01 13:17                 ` Stefan Monnier
2016-04-01 13:41                   ` Eli Zaretskii
2016-04-01 18:43                     ` Stefan Monnier
2016-04-01 19:47                       ` Matthew Leach
2016-04-01 19:58                       ` Eli Zaretskii
2016-04-03  0:53     ` Live System User
2016-03-31 16:32 ` Eli Zaretskii
2016-03-31 16:51   ` Matthew Leach
2016-03-31 16:56     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83pou9u7md.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=matthew@mattleach.net \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).