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

[Tom Lord]

This reminded me, by the way: the other solution that got brushed
aside but seems viable to me is to write a login-script that sets the
umask on the existing accounts appropriately for arch work when the
log-in is from an arch client.   OpenSSH, at least, has ~/.ssh/rc
which seems to exist for just this kind of purpose (the question is
how that script should distinguish those logins where umask should be
changed).  

Another solution, similar to that one, is to invoke ssh to run some
substem other than sftp, "archsftp" perhaps, and configure that
service appropriately server-side.    While I don't approve of the
=meta-data or copy-permissions hacks, I would be willing to
parameterize src/tla/libarch/pfs-sftp.c so that the string "sftp" is
parameterized.


    > From: Ethan Benson <address@hidden>

    > On Mon, Oct 06, 2003 at 09:46:09AM -0700, Tom Lord wrote:
    > > 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.

    > because from a system administrators point of view shared accounts are
    > simply unacceptable.  they provide absolutly no accountability for who
    > is doing what.

I think you must have skimmed over the part of my message that talked
about generalizations of the sftp-account solution.

When fs-like transports are used, certainly the possibility exists
that a compromised authorization can be used to remove or alter 
archives arbitrarily.    That's an entirely separate problem from
the one djw wanted to solve.

(It's also a fairly trivial problem to solve and would, as a side
effect, give yet-another work-around for the umask foo -- but it would
take more than the few days remaining to implement.  Not much more but
more.)

-t