Re: [Gnu-arch-users] expert needed: arch doesn't support multi-committer archives!

[Tom Lord]

    > From: Jonathan Walther <address@hidden>

    > Tom, any objections?  Xouvert needs to release something within
    > the next 10 days, and we're willing to tell our developers they
    > have to use your very latest developement version.

So, your priority is to solve a specific access control problem in a
specific environment.   Ok.

But, yes, I have nearly nothing but objections to this proposed
solution:

    > Can we get a "tla umask" command added, which will put the umask
    > in {arch}/=3Dmeta-info/=3Dumask, and then have the sftp
    > transport set the umask at the beginning of each session?

and those objections apply as well to the
"copy-permissions-from-parent" proposals.

A perfectly good solution to your priority problem seems to have been
provided already:

    James Blackwell
    >> The trick I use is to make an account just for an archive. I then add
    >> each developer's ssh key to that account's authorized_keys.=20

    > Thanks James.  That might work in my case, but overall it doesn't seem
    > to cover each of the 6 cases I mentioned.  For instance, if I only want
    > one user to be able to commit, but want only a particular group of
    > people to be able to do checkouts, how can one tell arch about the
    > permissions scheme?

There are several things to consider here:

a) James' solution generalizes to cover your "single-committer, group
   of readers" scenario perfectly well.   I suspect it generalizes to
   solve your other scenarios as well.  (e.g., You don't need to have
   just one account per archive -- you might have several -- the key
   thing is that however many you have, the purpose of those accounts 
   is specific to the archive and the access rights of the accounts
   and access of users to those accounts can be managed accordingly.)

b) Those other scenarios you mention are not your priority problem.
   It would be unwise to make solving some ill-conceived more general
   problem a prerequisite for solving the immediate needs of Xouvert,
   especially with a 10-day deadline, especially if we have reason to
   be confident that the other problems are already solvable without 
   adding new mechanisms to arch.

c) James' solution has an incredible virtue: using it, you can make
   the archive accessible (or writable) _only_ via sftp.  That's an
   extremely robust and desirable property: it means that you can
   leverage the authentication protections of sftp robustly and
   completely for this archive -- no danger of screwing it up when
   somebody makes a change to the archive using some other transport.

d) I think that James' solution, in combination with some very tiny
   administration scripts, generalizes to the various kinds of "fine
   grained" access controls that the "copy-permissions-from-parent"
   solutions attempt to provide.

In short, I think James has nailed the answer cold and I'm not sure
why his solution was so glibly brushed aside in favor of all the other
discussion.

That said, let me try to provide some of the design philosophy that
explains retroactively why James is exactly right:

Arch makes a design trade-off.   There is a choice:

        Pick one to do well:
        --------------------

        * Fully operable on dumb servers over nearly any fs-like
          transport.   Rely on the environment for access control.

        or

        * Build in access control.

The problem with nearly all of the proposals in this thread (the
"=meta-info" hacks and the copy-permissions-from-parent hacks) is that
confronted with that very clear design choice, they choose the third
option:

        * Build in half-baked access control that works for some 
          transports and not others and that implements a vaguely
          conceived access control model.

The right choice for arch is:

        * Fully operable on dumb servers over nearly any fs-like
          transport.   Rely on the environment for access control.

The proposed sftp-account hack is a great demonstration that arch's
choice on this design issue opens the door to re-using existing access
control and authentication mechanisms beautifully and in a manner than
can be customized to specific situations.

-t