[distcc] load management

[Martin Pool]

On  2 May 2004, Dan Kegel <dank at kegel.com> wrote:
> mbp at sourcefrog.net wrote:
> >I think the improvement in friendliness makes up for any nervousness.
> 
> That sounds like the way Microsoft thought when they were designing
> ActiveX!

There's no call for that sort of language. :-)

I think what you have is just timidness, rather than well-founded
concern.  

Let's see what the differences are between the daemon starting
automatically and starting ssh-agent with something like "eval
`ssh-agent`".

In either case the process listens on a unix-domain socket that is
only accessible to the user.  It is also accessible to any process of
that user, for at least two reasons: access to the socket is only
controlled by unix credentials, and secondly the server can be ptraced
or similarly molested by any other process of that user.

The ssh-agent exports some environment variables, either directly or
by writing a shell fragment:

  SSH_AUTH_SOCK=/tmp/ssh-vFNtj16414/agent.16414; export SSH_AUTH_SOCK;
  SSH_AGENT_PID=16415; export SSH_AGENT_PID;
  echo Agent pid 16415;

None of these are security critical.  The only one that even looks
like it is the location of the socket, but that is trivial to guess.

On the other hand, the current ssh-agent design requires (well, nearly
requires) that the daemon be started near the top of the tree of
processes that need to use it.  For example, it is quite hard to start
an ssh-agent from a running X session and have it be available to
every process in that session.  I don't think it gives any security.
It is merely cumbersome.

It might be that people want several different agents running at the
same time, in which case you need something like environment variables
to choose among them.  But I think it's fine to have reasonable
defaults.  Wanting just one ssh-agent per single logged on user is
pretty common.

I don't think it would be appropriate for ssh to automatically and by
default start a background process, just because that would be
surprising to users.  However, if you're using a program like the
mooted lfssh whose explicit purpose is to cache connections, then I
think it's reasonable.  If this function did go into SSH then I think
it would be OK to do it automatically when the option is turned on.

> The only thing that will take away nervousness is a good security analysis.
> Since that's hard, IMHO making the setup of the daemon manual helps
> a lot, since it makes it explicitly clear to the user that they
> are opening up a possible hole.

Where is the hole?  Or, in what way is automatically starting the
daemon when an option is given any different from starting it
manually?

> I posted my ideas on the ssh list, and it sounds like they like 'em
> to some extent (though they haven't made the jump to one daemon
> handling multiple remote systems, I think).  See
> http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=108348373615666&w=2
> and followups.

That's really good.  I had been meaning to ask for a while.

-- 
Martin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/distcc/attachments/20040503/5a549eca/attachment.bin