zsh-workers
 help / color / mirror / code / Atom feed
From: Phil Pennock <zsh-workers+phil.pennock@spodhuis.org>
To: "Eric P. Mangold" <eric@teratorn.org>
Cc: zsh-workers@zsh.org
Subject: Re: Update _twisted completion
Date: Mon, 4 Feb 2013 14:11:06 -0500	[thread overview]
Message-ID: <20130204191106.GA80149@redoubt.spodhuis.org> (raw)
In-Reply-To: <20130204190118.GN2279@ragnarok.teratorn.org>

On 2013-02-04 at 14:01 -0500, Eric P. Mangold wrote:
> If you run a process via your shell, unless you have some kind of magic
> sandbox I've never heard of, that process can stomp all over
> your shell if it wants to.

Processes can't change environ of their parent; environ in proc, for
instance, is read-only.  If you can attach with ptrace, then yes.

You're right though, in that the security models of most operating
systems, including Unix, are pathetically inadequate for the modern
world; digression: this is because the only early funders of research
into computer security were branches of the US military, whose model
included users running programs decided upon and installed for them, and
needing to protect one user against another.  The models don't include
users not trusting code they themselves run.

We're finally starting to see progress here with stuff like Capsicum,
capability systems providing sandboxing.  That will take a while to help
by default.

In the meantime, I sudo and ensure stuff listening for network
connections from beyond localhost is not running as my working account
(and ensure I have packet filtering to enforce the strong end-system
host model, at least as regards localhost addresses, so that they can't
come over the wire).

> I mostly agree with everything you are saying - but I still think what we
> are doing is acceptable, or at least *as acceptable* as what we've already
> been doing. I'm very much open to doing things better, but I would need
> some kind of concrete direction on what course to take. The problem of
> allowing programs to dynamically supply their own, more-or-less arbitary,
> completions in "safe" manner is certainly an interesting one.

A former employer had standard options in binaries built against their
libraries, so that a certain command-line flag combination would emit
output in a form designed for shell parsing for completion, giving more
power than crude --help parsing.  I think I've seen this elsewhere, but
have been failing to recall where.

(That output was actually designed for use with bash, but I was able to
make it work with zsh easily enough).

> And if you *have* "installed" Twisted, then presumably you already trust it, as
> you've just contaminated your copy of Python with its modules.

VirtualEnv.

-Phil


  reply	other threads:[~2013-02-04 19:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-03 17:53 Eric P. Mangold
2013-02-04  4:26 ` Phil Pennock
2013-02-04 16:48   ` Eric P. Mangold
2013-02-04 17:17     ` Peter Stephenson
2013-02-04 17:31     ` Phil Pennock
2013-02-04 19:01       ` Eric P. Mangold
2013-02-04 19:11         ` Phil Pennock [this message]
2013-02-04 18:38     ` Bart Schaefer
2013-02-05 10:05   ` Oliver Kiddle

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

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

  git send-email \
    --in-reply-to=20130204191106.GA80149@redoubt.spodhuis.org \
    --to=zsh-workers+phil.pennock@spodhuis.org \
    --cc=eric@teratorn.org \
    --cc=zsh-workers@zsh.org \
    /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.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).