RE: cvs commit/up's change file ownership in working dir.
Classification: UNCLASSIFIED From: Kaz Kylheku [mailto:[EMAIL PROTECTED] 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? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit/up's change file ownership in working dir.
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. AFIK, CVS really doesn't support this type of operation, and in fact it would probably break normal usage. Perhaps some other versioning tool does, or you can use the various checkin hooks to modify the behavior. If I was faced with this situation, I'd consider it a build issue. I'd have a make file in with these files, and my process (I'm assuming you've got some process that would be similar to a script running from cron?) would run a script that would do a checkout (as whatever user is aproprate, maybe give it a valid user with a home directory) or export, then run make on the Makefile. The Makefile would have whatever commands in it that are necessary to install the files: .SUFFIXES: *.cf *.conf .cf: chown whoever $ chgrp wheel $ chmod 600 $ mv $ /etc/. .conf: chown whoever $ chgrp wheel $ chmod 600 $ mv $ /etc/. This is only an example, write your own (not 100% if my syntax is correct even; security issues may be in above; check your permisions; etc...). That's just how I'd do it if I was faced with the problem, but YMMV. - Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit/up's change file ownership in working dir.
Patton, Matthew E., CTR, OSD-PAE wrote: Classification: UNCLASSIFIED From: Kaz Kylheku [mailto:[EMAIL PROTECTED] 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? SNIP 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. SNIP As Larry indicated the PRESERVE_PERMISSIONS_SUPPORT was found to not work as it was expected, and thus (from my perspective) it was marked in a way to allow it to atrophy. Why it has not been completely removed yet is unknown to me, perhaps it is something to look forward to with the final 1.12.X release. I suspect from your first email you have read some of the list archives that I have below[1-5]. I believe the wall you are hitting with your patch is due to three things: 1) As Larry mentioned in Re: cvs ci, cvs upd: Hard linkage problem [2] you need to include test cases in sanity.sh to verify that the functionality works and continues to work in the future and better to have those same ones crash/break/fail under the current code. Which is also mentioned in the HACKING file under Writing patches (tactics) 2) Everyone else using CVS has found that it is much easier/saner to manage file permissions and ownership using a build tool of some sort, and even specifically for /etc [3,4,5]. Some even give, what I see as, good reasons to keep permissions out of CVS, see Kaz Kylheku's responses [5]. 3) Because PRESERVE_PERMISSIONS_SUPPORT code as a whole is notoriously buggy and contains at least one known problem that can cause unrecoverable data loss[6] and has been for quite some time, (my opinion only) no one wants to even accept a patch to it that does not fix it all and accept maintainer ship for the long haul. The original (cleaned up) vision for Preserve Permissions can probably be seen in the references from Jim Kingdon's email[1]. [1] Subject: Re: CVS and PreservePermissions http://mail.gnu.org/archive/html/info-cvs/2000-12/msg00378.html [2] Subject: Re: cvs ci, cvs upd: Hard linkage problem http://www.faqchest.com/prgm/cvs-l/cvs-00/cvs-0005/cvs-000505/cvs00051019_22271.html (I wish mail.gnu.org/archive had most of the pre mid 2000 posts. From time to time I find many good answers in my personal archive back through Dec. 99, and can not reference them online.) (solutions) [3]Subject: Re: CVS management of /etc - permissions problem http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00353.html [4] Subject: Re: using cvs to contol system files http://mail.gnu.org/archive/html/info-cvs/2002-10/msg00352.html http://mail.gnu.org/archive/html/info-cvs/2002-10/msg00351.html [5] Subject: Re: CVS management of /etc - permissions problem http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00348.html http://mail.gnu.org/archive/html/info-cvs/2001-09/msg00373.html [6] from Larry Jones. I am pretty sure Larry got tired of typing this and has it in a permanent cut and paste buffer somewhere as it is the same (or almost so) each time preserve permissions comes up. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs commit/up's change file ownership in working dir.
Classification: UNCLASSIFIED If I check out stuff into /etc (or /var/www if you like) as root, You're foolish; you should never run CVS as root. er, why not? In client-mode? Right now I'm not using it under sudo but that is the end goal so that only cvs up is allowed to be run as root by an otherwise non-privileged uid. Are you telling me CVS is so bug-ridden that it's untrustworthy? That despite the legions of problems, practically the entire opensource movement uses it? and often in pserver mode (which runs as root I might add - not that it necessarily needs to most of the time but nobody has written any examples I've seen that didn't have it running as root) no less? Come on now... CVS is a revision control system, it is *not* a complete file system manager. huh? A file system is nothing but a collection of files in a hierarchy. I don't use CVS to manage my binaries (though I easily could and it would be right useful actually - screw RPM), just some configuration files. The active set is nothing more than a checkout of the repository that is never edited in-place. How does this diverge in any way from CVS' design and normal use? You should check out into a working directory and include a script (or a makefile, or whatever) that can be run to move the files into the correct places and set the ownership and permissions correctly. I already said I could run mtree after a checkout to set perms but I (incorrectly) wanted to avoid that. You're right and I'm wrong. In keeping with the unix tradition of 1:1=task:binary lets strip out every last chown/chmod out of the CVS codebase as it relates to checkin/out of user files (house-keeping stuff I can't comment on just yet) and deep-six the PRESERVE_PERMISSIONS code since it really is none of CVS' business; past, present or future. fopen(2) is all we need, right? So in addition to my patch it looks like we might need to yank the odd line from checkin.c. client.c has this change_mode() which is called once in client.c and server.c that looks suspicious and probably a few others that seek to modify permissions. I can happily live with consistant refusal by CVS to muck with file ownership and modes besides honoring umaskCVSUMASK. I just don't like inconsistant behavior. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit/up's change file ownership in working dir.
Patton, Matthew E., CTR, OSD-PAE writes [quoting me]: You're foolish; you should never run CVS as root. er, why not? In client-mode? Right now I'm not using it under sudo but that is the end goal so that only cvs up is allowed to be run as root by an otherwise non-privileged uid. Are you telling me CVS is so bug-ridden that it's untrustworthy? That despite the legions of problems, practically the entire opensource movement uses it? and often in pserver mode (which runs as root I might add - not that it necessarily needs to most of the time but nobody has written any examples I've seen that didn't have it running as root) no less? Come on now... Pserver runs as root just long enough to authenticate the client user; as soon as the user has been authenticated, it drops root and runs as that user instead. CVS is not so bug-ridden that it's untrustworthy, it was never *designed* to be trustworthy, and so should not be trusted. You should never run *anything* as root unless you absolutely have to, and I would certainly think twice (or thrice, even) about running anything as complex as CVS. Without too much effort, anyone with access to the repository can plant commands that you'll end up running as root without even knowing it. CVS is a revision control system, it is *not* a complete file system manager. huh? A file system is nothing but a collection of files in a hierarchy. And a whole bunch of metadata like file type, ownership, permissions, link counts, flags, modification times, etc. CVS makes some attempt to manage the few bits of that metadata that make sense for working copies of files, but (currently) makes no attempt to manage all of it (although the notoriously buggy PRESERVE_PERMISSIONS code did make an attempt to manage most of it). active set is nothing more than a checkout of the repository that is never edited in-place. How does this diverge in any way from CVS' design and normal use? Normal use is to check out an individual *working* directory, not a production directory that requires specific ownership and permissions. In keeping with the unix tradition of 1:1=task:binary lets strip out every last chown/chmod out of the CVS codebase as it relates to checkin/out of user files (house-keeping stuff I can't comment on just yet) and deep-six the PRESERVE_PERMISSIONS code since it really is none of CVS' business; past, present or future. fopen(2) is all we need, right? So in addition to my patch it looks like we might need to yank the odd line from checkin.c. client.c has this change_mode() which is called once in client.c and server.c that looks suspicious and probably a few others that seek to modify permissions. Now you're just being silly. The notoriously buggy PRESERVE_PERMISSIONS code is already deep-sixed; it's been completely disabled for a very long time. There are no chown() calls in CVS outside of that code. Some mucking about with permissions makes sense in the environment CVS was intended for. For example, CVS makes the RCS files in the repository read-only (just like RCS does) to prevent people from mucking about with them. It also allows you to ask for checked-out files to be read-only. It makes a feeble attempt to track execute permission since it's convenient to be able to execute a script that you've just checked out. It also makes a feeble attempt to track read/write permission to provide a modicum of privacy from prying eyes. But it makes no attempt to track all of the metadata, nor should it. -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs commit/up's change file ownership in working dir.
Classification: UNCLASSIFIED [EMAIL PROTECTED] wrote: anything as complex as CVS. Without too much effort, anyone with access to the repository can plant commands that you'll end up running as root without even knowing it. can you elaborate on this? what magic files is the cvs server going to be looking for? Are we talking about cvs running the various support scripts (loginfo, commitinfo etc)? That I understand. I guess it wasn't clear, the CVS *server* is NOT running as root. only the client is. What kind of tricks is the client up to then? Some mucking about with permissions makes sense in the environment CVS was intended for. For example, CVS makes the RCS files in the repository read-only (just like RCS does) to prevent people from mucking about with them. these kind of games don't make sense to me. the parent directory in the repository is frequently if not almost always group-write (because of CVS artificial design limit). Taking the 'w' bit off a file isn't going to stop anything. And if the repository is remote, the tactic is even more of questionable value is it not? But by implementing this you've artificially limited the cvs admin's options by a considerable amount. eg. if the parent dir is g=RX then by tagging individual files with g=RW I can support 2 distinct classes of persons within the same group definition with the potential to add another: those that are members of the group and can read all files, and those that can edit certain and possibly all files. If the gid of the parent dir is different than the files contained within, I have another group that can add files to the collection to boot. This really isn't an unreasonable or overly complex setup. If one's needs are trivial then you don't care if you have this or not. It also allows you to ask for checked-out files to be read-only. that's fine. Does not need chmod to do that but rather the proper flag to fopen() which we do for the most part I think. It makes a feeble attempt to track execute permission since it's convenient to be able to execute a script that you've just checked out. Feeble indeed. if umaskCVSUMASK=027 for example, a script that was originally 555 or 755 is now 530 or 730. oops!! It's still executable by the user, but what what happens when I check that file back in? And wasn't this supposed to be a build matter? I will grant you that it is nominally user-friendly not to have to make the script executable before being able to use it, but the correct way is to support 'mode' as an attribute of the file to be set just like commit messages are and NOT simplistically grabbing them off the working file which was where the whole mess started. It also makes a feeble attempt to track read/write permission to provide a modicum of privacy from prying eyes. It's the comingling of repository permissions with those of the working dir which is the fundamental fallacy here. Visibility within the working dir is the user's umaskCVSUMASK's problem and his savvy with respect to his work space and the nature of the files. The repository content's visibility and control over checkout/in is the CVS admin's job and responsibility and is 100% independent of the developer. The developer should not have to resort to a script to pound the checked out contents into a suitable form when 3 simple fields can take care of 90% of the problem regardless of what the cvs admin might be doing/have done to the repository to suit his requirements. Yes the two entities cooperate but the programmers really have no business dictating preconditions to the admin (oh, please treat 'x' as special, or don't set CVSUMASK to such and such, etc). The admin needs to know who should have access and to what and if he wants to be tightfisted about permissions and cross-project visibility that's his call. How the content shows up in the working dir is the developer's problem. Therefore the developer has only two paths available to him: tagging the file with some fields, or writing a script to munge things. CVS wasn't designed with security in mind as has been said. Well then CVS has no business interjecting itself where it don't belong and especially making feeble attempts at it and pretending to do something. Do it right, or don't do it at all. Don't get me wrong, I like CVS a lot. I'm just heavily annoyed at inconsistent behavior and don't like band-aids or hacks which are worse than the disease when design can obviate them. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs commit/up's change file ownership in working dir.
[ On Tuesday, January 6, 2004 at 17:17:41 (-0500), Patton, Matthew E., CTR, OSD-PAE wrote: ] Subject: RE: cvs commit/up's change file ownership in working dir. can you elaborate on this? what magic files is the cvs server going to be looking for? Are we talking about cvs running the various support scripts (loginfo, commitinfo etc)? That I understand. I guess it wasn't clear, the CVS *server* is NOT running as root. only the client is. What kind of tricks is the client up to then? Look -- just DO NO EVER run any part of CVS as root. Period. It's not safe, and it's not designed to run as a privileged program at any level, and it's not necessary. these kind of games don't make sense to me. The files in the repository are kept in read-only mode because that's the best way to avoid gross software errors from causing problems. It's not to protect the files from the users but rather to protect the files from the programmer. But by implementing this you've artificially limited the cvs admin's options by a considerable amount. On the contrary -- you think you can have something that you simply cannot have in the first place. You must give up on your attempt to have CVS do anything more than it already does with file permissions. CVS is _NOT_ a build tool. Learn to use the right tool for the job. CVS wasn't designed with security in mind as has been said. Well then CVS has no business interjecting itself where it don't belong and especially making feeble attempts at it and pretending to do something. Do it right, or don't do it at all. CVS isn't doing anything for security beyond what any average plain text editor will do -- you're mistaken if you think otherwise. Don't get me wrong, I like CVS a lot. I'm just heavily annoyed at inconsistent behavior and don't like band-aids or hacks which are worse than the disease when design can obviate them. The problem here is _only_ that you're using the wrong tool for the job you're trying to do. If you were not abusing CVS in the way you're trying to then you wouldn't see any inconsistencies (well there's one, but it's an ancient artifact of RCS backwards compatability). Write a script to install the files from your working directory into their final locations and have that script do the right thing with permissions, ownerships, symlinks, hard links, and whatnot. Check the script into your CVS module along with your files. That way you will suddenly be able to properly version all those attributes of a file that cannot be stored in an RCS file. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs commit/up's change file ownership in working dir.
Classification: UNCLASSIFIED
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. I think we need to move beyond simply creating in the working
directory a file owned by whatever fopen(2) comes up with. My repository
files are owned by entirely different users and groups and have no bearing
on what is in the working dir and have a 0440 visibility to keep unneeded
noses away from RCS files. Because that's the way they have to be.
In order that I don't have to go traverse the repository for files that are
NOT 0440 I set CVSUMASK=027 for the user checking in. Unfortunately this
also means that ANY checkouts will apply the repository's permission bits to
the working set which is just silly. We can't on one hand say what goes on
in the repository is entirely separate and irrelevant to the working set
like it was suggested about the use of internal RCS revision numbers, or
requiring the user to take their own steps to initialize a build
environment with supplemantary scripts instead of storing meta-data within
the RCS files, yet turn around and let repository file permissions influence
the working set. Which is it going to be? IMO we *should* support such
obvious and useful meta data as file modes and file ownership with the full
understanding that this is not as entirely simple as one would hope.
Does anyone actively use the PRESERVE_PERMISSIONS_SUPPORT capability? Is it
being maintained? My quick look thru the source says it stuffs owner,
group, permissions as fields into the RCS file. And it also appears that it
stores the numeric value of uid/gid which is an immediate problem when you
consider that these values are not portable from one machine to another let
alone different OS's. We need the textual representation if nothing else. In
any event the values are derived from the working file's attributes which in
my mind quickly poses significant problems in real life.
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. 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. So when he checks
in a file and 'todd' updates his working set, todd gets a bunch of mode 666
files which he desperately doesn't want. (plus there's the little matter of
OS's with non-unix conventions) So who gets to set uid/gid/mode? Do we
subtract umask from whatever value was last set by he who checked in? What
if 'security Todd' decides every file should be 600. We still have a
problem. ok maybe we take this out of the users hands entirely. only 'cvs
admin' can set owner,group,mode and cvs will make a best effort to comply on
checkout/update (but never in check-in/commit) in so much as the uid running
cvs is able. Furthermore the admin can set repository or project-wide
defaults should it be desired.
There was some discussion about using CVS and files in /etc back in 2001 but
I didn't see any real solution presented except to say CVS couldn't give a
rip, it's not relevant, CVS shouldn't deal with meta-data, and so forth -
and if you want it, write a script to set perms on checkout. But this is a
non-solution and ignores IMO a legitimate need. And yes I can use mtree and
a file spec to implement it should I have to go that route.
Thoughts? But the first thing that has to happen regardless is tossing the
derivation of file modes in the working set from whatever the repository
happens to have. The patch below takes care of that I think. The source is
from v1.11.9
--- rcs.c.orig 2004-01-05 13:37:40.0 -0500
+++ rcs.c 2004-01-05 13:58:08.0 -0500
@@ -4610,10 +4610,14 @@
workfile);
}
- ret = chmod (workfile,
-change_rcs_mode
-? rcs_mode
-: sb.st_mode ~(S_IWRITE | S_IWGRP | S_IWOTH));
+ if (change_rcs_mode)
+ {
+ if (chmod (workfile, rcs_mode) 0)
+ {
+ error (0, errno, cannot change mode of file %s,
+ workfile);
+ }
+ }
#else
if (fclose (ofp) 0)
{
@@ -4621,14 +4625,7 @@
return 1;
}
- ret = chmod (workfile,
-sb.st_mode ~(S_IWRITE | S_IWGRP | S_IWOTH));
#endif
- if (ret 0)
- {
- error (0, errno, cannot change mode of file %s,
-
Re: cvs commit/up's change file ownership in working dir.
On Mon, 5 Jan 2004, Patton, Matthew E., CTR, OSD-PAE 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.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
