info-cvs
[Top][All Lists]
Advanced

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

Re: cvs commit/up's change file ownership in working dir.


From: Kaz Kylheku
Subject: Re: cvs commit/up's change file ownership in working dir.
Date: Mon, 5 Jan 2004 11:36:04 -0800 (PST)

On Mon, 5 Jan 2004, Patton, Matthew E., CTR, OSD-PA&E wrote:

> I have a file owned root.named. root wasn't a member of said group but I
> tested with root being a member (not primary group) and it still does the
> same thing (if 'named' were the primary group for 'root' I'd be ok in this
> one very narrow instance). When I commit a file, cvs is changing the file
> ownership to the default for that account: namely root.root which destroys
> my setup.

Read up on the setgid bit on directories. When you create a file or
subdirectory, it does not automatically inherit the group ownership of
the directory into which it is linked. 

You can get that behavior, the parent directory has to have the setgid
bit set in its permission mask.

For executable files, setgid means ``run the process under this
effective group ID''. For directories it means ``create new elements
with this group ownership''.

> I think we need to move beyond simply creating in the working
> directory a file owned by whatever fopen(2) comes up with.

No we don't. The POSIX operating system interface is designed such that
programs can use the fopen() function without worrying about it. It does
the right thing based on the process security context, umask, and
permissions of the directory.

> Does anyone actively use the PRESERVE_PERMISSIONS_SUPPORT capability? Is it
> being maintained? My quick look thru the source says it stuffs "owner,

Versioning permissions is a bogus idea. When you check out files, they
should be created such that they are accessible to you.

Client-server CVS does not require the sharing of any authentication
databases; you can check out from a remote server without having access
to its password database. If the files in the CVS server are
group-owned by ``cvsusers'', there is no need for such a group to exist
locally. Your client machine doesn't even have to run a UNIX-like client system.

> For example if "joe" and "todd" are editing files, whoever commits last
> could end up setting "file owner|group; " to their uid/gid because that's
> how the file is in their working set.

It all works properly because it's based on the UNIX model. 

Imagine that instead of using the CVS client and server, joe and todd
were logged into the CVS machine and were hand-editing the files in
the repository.

The operating system already has features to handle this type of
sharing. It's a multi-user system! CVS just builds on it by acting as
a remote shell, if you will.

Where would we be if you couldn't log in a bunch of users into a UNIX
box, put them into a group, and have them share some files in a
directory? Hello?

>If 'jane' does a 'cvs up' her files
> will have to be owned by her because I'm pretty sure she won't be 'root' and
> thus able to chown/chgrp arbitrary file owners ('joe' or 'todd') to her
> files.
> 
> Permissions are more challenging. Sloopy 'joe' can't be bothered with
> security so he just mode 666's every file he deals with.

Firstly, Sloppy Joe can't change the mode of files that he does not own.
Secondly, there can be a nice

  umask 007

in the global login script which will cause Sloppy Joe's, and everyone
else's files to be created 0660. Of course, users can override that or
use chmod. That is their choice.

You can't implement security if you have users who don't care about it.
No matter what you implement in the computer system, uncooperative
users can leak information and find ways to delegate their access to
unauthorized users.





reply via email to

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