[cvsnt] linux host, and ACLs

[David Somers]

duane_ellis at franklin.com wrote:

> duane> I don't see how I can stop users from "cd /to/the/CVSROOT"
> duane> and looking around.
> 
> david_sommers> cvs and cvsnt run as client-server system... so your end
> david_sommers> users won't be able to cd to the repository as its on
> david_sommers> another host (unless you are doing something extremely
> david_sommers> dumb like making the repository available via a share
> david_sommers> and using the :local: protocol.)
> 
> Hmm... "unless you are doing something extremely dumb..."
> 
> In effect, yes, I am doing something "extremely dumb"...
> I seem to do that all too often... :-) don't we all...

Hehehe... well, you're use is a tad eccentric.

> Reason: the box is *not* dedicated,  every user will have shell
> access to the machine, I need this feature for other purposes.

Oh well...

> Remember: It's a unix server, and every user will have a shell
> account on the machine. They will, via their shell account, be
> able to "cd /to/places" on the same file system as the
> repository. Thus, I believe it is much like ":local:"

> I could enforce an ":other-protocol:" for local machine
> access... but that does not seem right. Maybe it is,
> I'm not familure with CVSNT specific things.

Use :pserver: (or whatever) to access localhost. Use file-level ACLs to keep
your users out... only allow the cvsnt service to read/write the
repository.

> 
> I believe, as Gerhard suggests, the file system ACLs are required.
> Perhaps even as far as running the CVS server as another user
> (in Unix terms, as a "SETUID" application) which does have
> access to the repository.

That's the simplest solution.

> 
> gerhard_fiedler> ... You may think about running the cvsnt
> gerhard_fiedler> service as its own user, give it only access
> gerhard_fiedler> to what you want cvsnt to access, and prevent
> gerhard_fiedler> all other users from accessing the repository
> gerhard_fiedler> (using file system ACLs).
> 
> But I have questions about Gerhard's reply.
> 
> Yes, that make sense. But.. I don't understand your other suggestion.
> 
> gerhard_fiedler> [make a hole in your firewall for] port (2401 by
> default).
> 
> I don't understand the security model you describe. Please
> tell me what is supplying the encryption for that other port.
> 
> Remember, I am already authenticated to the system by SSH,
> and unless it is secure, I can't open any other port.
> 
> To help understand my question, here's a banking example,
> I hope it makes my concern clear:
> 
>         I login to the bank via a secure https server on port 443
>         (via SSH to my cvs server on port 22)
> 
>         I can then use the unsecure port 80 to view my bank statement
>         (port 2401 for cvsnt protocol, for "cvs status")
>  
>         To transfer funds, in or out of my account, port 80 again)
>         (Port 2401 for cvsnt protocol to checkin and checkout)
> 
> I'm sure I'm missing something... As I remember, the CVS
> protocol is not secure, it is plain-text.
> 
> What provides the encryption and security for CVS transport
> on port 2401?

All cvs[nt] networking happens via port 2401 (unless using :local: which
directly access the repository). If you just happen to use a secure
protocol (e.g. :sserver:) then the data link is encrypted. Unlike
http/https, the plain and encrypted cvs stuff happens over the same port.

-- 
David Somers
typographer/programmer/whatever