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

[Patton, Matthew E., CTR, OSD-PA&E]

Classification: UNCLASSIFIED

> From: Kaz Kylheku [mailto:address@hidden

> Read up on the setgid bit on directories.

I have extensive use of setgid on my REPOSITORY. setgid is not a solution
when managing things like /etc/*. 

> > 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.
...
> Versioning permissions is a bogus idea. When you check out files, they
> should be created such that they are accessible to you.

Then my patch to eradicate the chmod'ing of checked out files based on the
respository's file perms is all the more necessary - who came up with that
one anyway? I am *NOT* interested in versioning user.group or mode of the
files. I simply want to optionally set those attributes so that WHEN a file
is checked out it gets the proper permissions - euid of the process
permitting. Unspecified attributes would have NO effect on current and
default behavior. If the attribute for 'group' were blank or unset, then if
the working dir was sgid then the file would get this default group
ownership per standard posix.

If I check out stuff into /etc (or /var/www if you like) as root,
configuration files break all over the place (per this posix behavior)
because the process that needs to read them are not the same primary group
as root and checking out mode 444 may not be appropriate and as I've already
shown this gratuitous chmod'ing of working files to match respository perms
breaks things on it's own. If I *know* what filespec they should be, I
simply want to be able to set it as an attribute of the RCS file so I don't
have to go back and run mtree every time I checkout a file.

> 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?

you are entirely missing the point I'm afraid. My little example describes
just one of a few problems wherein CURRENT implementation of
PRESERVE_PERMISSIONS would end up overwriting the perms/mode of a file with
whatever person was last mucking with it. Again, I repeat that I simply want
to store a perm+mode attribute in the RCS file so that when it's checked out
it gets those perms unless of course the euid of the process (eg. non-root)
can not actually do the chown/chmod in the working directory. I don't care
about these latter failures.

Scenario: N system admins. they checkout a machine's configuration into
their private working directory. they all are not currently root (or I'll
shoot them) and so the files are all owned by them with whatever default
mode per standard (umask etc) procedure. They do their edits, check them
into the repository. Now when a process on the host goes to the respository
to fetch it's new/updated configuration files the perms of these Read-only
checked out files had BETTER have the right perms on them or the processes
that read them will fall over and die.

Get it?