[48341] in SIPB bug reports
A proposal to encourage more use of /mit/sipb/bin
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Mon Aug 19 01:23:52 2013
From geofft@MIT.EDU Mon Aug 19 05:23:52 2013
Return-Path: <geofft@MIT.EDU>
Delivered-To: bug-sipb-mtg@CHARON.mit.edu
Received: (qmail 16428 invoked from network); 19 Aug 2013 05:23:52 -0000
Received: from mailhub-auth-1.mit.edu (18.9.21.35)
by charon.mit.edu with SMTP; 19 Aug 2013 05:23:52 -0000
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r7J5NYT2017438;
Mon, 19 Aug 2013 01:23:37 -0400
Received: from localhost (team-rocket.mit.edu [18.96.2.200])
(authenticated bits=0)
(User authenticated as geofft@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r7J5NW6P014768;
Mon, 19 Aug 2013 01:23:33 -0400
Date: Sun, 18 Aug 2013 22:23:32 -0700 (PDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: bug-sipb@mit.edu, gsipbbin@mit.edu
Subject: A proposal to encourage more use of /mit/sipb/bin
Message-ID: <alpine.DEB.2.00.1308182122200.15460@team-rocket.mit.edu>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
[ Followups to bug-sipb only, please; add yourself if you want to see
replies ]
A couple of us were talking on -c barnowl about the fact that barnowl and
several other recent projects with widely-used binaries (mosh_project
comes to mind) use their own lockers instead of the sipb locker, which
means that, absent additional effort, they lose out on replication
(including cross-cell replication). It would be good to figure out how to
make new projects happy to put release binaries in the sipb locker and
recommend use of those, instead of using their project lockers directly,
since the sipb locker already offers this.
One good reason for having your own locker is least-privilege: there are
124 people on gsipbbin, and 7 on barnowl-locker, so there's a lot of
attack surface for honest mistakes, compromised accounts, etc. Even trying
to trim "inactive" folks on gsipbbin will only go so far, since there's a
lot of software with lots of different maintainers, and having all of them
on every project's ACL will still be a lot of folks.
What if we instead make e.g. /mit/sipb/bin/barnowl be a symlink to
/mit/sipb/project/barnowl/bin/barnowl, where /mit/sipb/bin is tightly
restricted (the same way that making Hesiod pointers is tightly
restricted), and /mit/sipb/bin is accessible only to barnowl maintainers?
My original thought is that /mit/sipb/bin and /mit/sipb/projects could be
writable by system:administrators -c sipb only, which basically makes
creating a new project in the sipb locker just like creating a new project
locker in the SIPB cell. Karl pointed out that it should be fine to make
them system:gsipbbin i ("insert"), allowing everyone on the existing
gsipbbin list to create new projects self-service like you can now, but
not change / take over existing projects. Once a symlink is created, the
security properties of telling people to run `athrun sipb barnowl` are
largely like the current properties of saying `athrun barnowl barnowl`.
What do folks think about this plan? Note that it'd require shaking up
everything in /mit/sipb/bin, although if folks feel like it would reduce
maintenance of the less-loved binaries in there where least-privilege
maintenance isn't a feature, one option would be to move everything
current to e.g. /mit/sipb/project/collab-maint/, and give all of gsipbbin
access to that directory. New stuff could be in collab-maint or in a
separate directory depending on preference.
(Read "arch/@sys/{bin,lib,man,etc.}" for "bin" in the above discussion.
Each project that cares would need its own arch/* structure, and links
would go from the top-level arch/x/bin/y to project/y/arch/x/bin/y; this
is straightforward but annoying, so I left it out of the main
description.)
I'm also basically completely unlikely to personally implement this, but
I'm posting here for discussion and in hopes that someone else will feel
enthusiastic about implementing whatever we reach consensus on.
--
Geoffrey Thomas
geofft@mit.edu
