info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: filesystem ACLs vs. CVS


From: Greg A. Woods
Subject: Re: filesystem ACLs vs. CVS
Date: Fri, 22 Feb 2002 14:32:49 -0500 (EST)

[ On Friday, February 22, 2002 at 10:28:16 (+0100), Peter Ring wrote: ]
> Subject: RE: ANN: cvssh - secure ext-to-pserver bridge
>
> We need to control access on files that cannot (i.e., CANNOT) be logically
> arranged into disjunct directories.

Certainly you can rearrange your files.  You just don't want to.

Anything like this is possible.

You could build a script that re-arranged the files after they've been
checked out so that they can appear to be in the same structure they are
now, perhaps just with symbolic links to a new hierarchy so that commits
could be done from within the working directory and edits could be done
from within the re-structured directory.

> So I can't rely on the usual mechanism
> with a number of project groups, sticky bits on directories in the
> repository, and direcories and files owned by project groups.

Assuming you're talking about write access then even if you use
filesystem ACLs you must segregate your files into different directories
based on your needs for access control.

CVS (and indeed RCS) can only use the directory permissions to control
commit/tag (write) access to files.  You can't "fix" this without
changing fundamentally the way RCS files are accessed.

> Is *info scripts the way to go? It's easy enough to control commits, but I
> can't find an obvious way to prevent checkout or update from getting
> everything. Except by somehow controlling the group owner of each individual
> file.

Ah, you're also talking about read access.....

No existing *info script can intervene during checkout or update.  There
is though the '-o' and '-u' modules file option, which would allow you
to write a script which removed files after they were checked out.
Pretty damned easy to subvert though.

No, you can't control the group owner of the files either, at least not
without going to a great deal of effort (i.e. internally re-engineering
how CVS re-writes ,v files).

I don't know 100% that this applies to all host operating systems, but
under *BSD for certain the group owner of the ,v file will immediately
revert to being the same as the group owner of the repo directory.

There's also the issue that anyone with access to the protected files
might check them out into an unprotected working directory.....

> It would be a lot easier if I could rely on ACLs supported by the
> filesystem. Oh, but wait; it comes to my mind that we do have servers
> running a filesystem with ACLs ... It's just that we don't like them exposed
> outside the firewall.

I doubt ACLs will buy you anything here either, at least not without
adding explicit ACL support to CVS.  RCS files are re-created every time
they are modified (or tagged).  That means that without ACL support in
CVS the new one will have the default ACLs any file created by the user
would have -- any ACLs set on the old ,v file would be lost.

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]