Re: [Gnu-arch-users] Re: Linus

[Colin Walters]

On Mon, 2003-10-13 at 02:33, Miles Bader wrote:
> On Mon, Oct 13, 2003 at 01:49:03AM -0400, Colin Walters wrote:
> > How do you want me to prove my thesis?  The total lack of nontrivial
> > sites using multiple writers to an archive could be construed as a
> > fairly strong argument in my favor, for one thing.  On the other hand
> > you may just interpret it as arch not being popular enough yet.
> 
> Or interpret it as being a sign that people prefer arch's distributed model.
> [My money's on this one actually]

I think it's likely a combination of all 3.  In what proportion we'll
probably never know.

> I must admit I'm confused as to exactly what you _do_ think is acceptable on
> a large system.  

Arch should work well with one Unix group per project, as sites like
SourceForge already offer.

> Presumably since you (elsewhere) advocate using file-system
> permissions, you think it's OK to have a system-user per archive-committer,
> right?  

Of course that's fine, IF it's being offered.  The issue is that I doubt
many sites will want to support this.

> Since you're pushing for the copy-permissions hack, what does that solve?
> It (1) avoids the need to set the umask specially on login, and (2) allows
> different branches(&c) to use different permission bits.

3) Would work for both sftp:// and file:// transports
4) Is extremely familiar to users of CVS and just Unix in general in
that it's based simply on filesystem permissions

And most importantly:

5) Generally doesn't require system administrator intervention.  The
user can resolve pretty much any situation they can get themselves
into.  That's probably not going to be the case if the sysadmin has to
edit some centralized ssh subsystem script or whatever to change
permissions.

> (2) Is only useful if you have some access-control problem that can't be
>     solved by changing a file's group-id, which seems true only if you need
>     to enforce certain types of access control, but which as far as I can
>     see is _not_ needed to enforce the typical sort of control needed on
>     e.g. savannah.

Presently you can't solve this just with a groupid because tla doesn't
copy the permissions!

> (1) Is useful even for cases where you use a single global file permission
>     (perhaps with multiple gids), because it avoids any problems with setting
>     the umask in the sftp server/local user's environment.  Is the only
>     issue then?

No, see above.