Re: pserver user id's
foomonkey wrote: Hello. I have a repository configured and working with pserver. I want to restrict user's permissions on subdirectories in the repository. I don't want user A to see user B's projects and vice versa. In my $CVSROOT/CVSROOT/passwd file, I have something like: divap:YBGW948yOKKSA:cvsadm divap is a user on the system. The user id under which CVS runs is 'cvsadm'. In $CVSROOT, I have a subdirectory that looks like this: drwxrws--x 3 divapdhdev 512 Jul 06 17:16 divap/ This all works fine except that, the pserver user divap can read ALL the projects in all the other subdirectories because on the server, he is actually running as cvsadm (see the passwd file entry above). If I change the passwd file to look like this: divap:YBGW948yOKKSA:divap I get an error when I try to run a 'checkout' on a project in the divap directory that says: cvs [checkout aborted]: unrecognized auth response from cae1axp1: setgroups: Not owner I don't want everyone to run as the administrator account (cvsadm) and the docs seem to indicate that they can run as themselves (their shell accounts) but I get the above error. Any help would be GREATLY appreciated. Andrew Obviously divap does not have write access to the repository structure. In my pserver setup, the repository directories files are owned cvs:cvs, and my users run username:password:cvs. My admin users DON'T have the :cvs part at the end, but instead are members of the linux group cvsadmin, who are granted access automatically (I'm not sure if it's by pserver or by CVS itself). Note: I am told it is ill-advised to use admin accounts for regular use. To get back to the original requirement (restricting access on a per-project basis), I believe that CVS/pserver does not conveniently suppport the granularity of access you require. julian. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Todd Denniston wrote: CLIP The only reason I am using pserver is that it allows my users to have CVAS controlled access to the respositories without giving them dierct write access to them. If you can suggest another way of doing that, I'd be glad to use it. As Far As I Know, you are correct, but at best you are only protecting them from a fat fingering while in the repository and do not have malicious intent. The first rule of the repository for users should be that if you are not the admin you never execute any non cvs command against it. The first rule of the repository for admins is back it up appropriately, as hardware/network/software faults can damage the work. With these two rules, I believe you should have at least as good a set of protection as pserver would get you, because you don't have developers with malicious intent and who follow the rules :} Pretty much true: if it isn't, I've got worse problems :) As long as the developers are using only :ext: cvs commands against the repository, I believe you should still be able to meet your FAA requirements: FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. but would be counting on the backups to prevent you from loosing any lifecycle data, which is what you would be back to if they were looking at you with strictness when there is a known hole in pserver. In final, Yes using pserver will probably make it easier to show up front that everything meets the requirements, but in the past it has been the bain of security with cvs. I belive you are in the middle ground between the restricted execution of CVS Mark D. Baushke told you about, and the trusting developers ground of :ext: on a system they can execute more than cvs on. I further belive that you are only mildly protected from what you worry about, using your method. Where as one of the restricted execution of CVS would probably allow much more of the FAA level security lock down and logging. if you want further reading I suggest searching the list's archive for Greg Woods AND pserver OR Greg Woods AND authentication AND|OR authorization. I think the horse is dead, so I'll stop beating. SNIP Well I think the horse has completed the track, and I think we've won the race, inasmuch as I have fat-finger protection, which is all I need: I am backing up, after all, as you suggest (and as insisted upon by our friends at the FAA, in fact), and the backup includes logs, so I'm meeting the obligation. There is rarely a perfect solution for special needs situations such as this, but I think I've got the closest practical solution, and as long as my local FAA officer is happy, then so am I. Todd, you obviously spent plenty of time thinking and writing. Thank you very much for your opinions, insight and help. julian. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: pserver user id's
foomonkey wrote: I believe my problem lies in that my inetd.conf specifies to run cvspserver under the cvsadm user account. When I have my $CVSROOT/CVSROOT/passwd file configured like, username:password:cvsadm, everything works great. With the exception that user A can see user B's projects and vice versa. This is because cvsadm owns the repository directory structure. The mode for it is 771. When I change the passwd file to username:password:username, this does not work. I get the previously mentioned error. My belief is that pserver is running as cvsadm but wants to run in the context of the user specified in passwd. I don't know that this is possible unless pserver is running as root. In a sandbox environment, I have changed pserver to run as root (in inetd.conf) and it works correctly. I may be missing something but that's the way things appear to me. Is there any danger in having pserver run as root? inetd.conf contains many other services running as root. I realize that ANY service running as root or otherwise introduces certain vulnerabilities. Thanks for any clarification anyone can provide. Andrew As Larry said, [x]inetd must run cvs as root. But you don't want to have the repositories owned by an admin account member - it isn't necessary, and gives rise to the problems you're experiencing. Running cvs as root - as Larry says - allows it to control access to other users. To that end ... Create a separate user and group cvs, and change ownership of the repository to that user. Put :cvs after all entries in your password file (that are not admin users, of course). You already have drwxrws--x on your repository directories, which is good. The project files need/should only be 440, CVS takes care of everything. julian. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Todd Denniston wrote: Big question: What do you think using :pserver: at this point, gain you and your users over just :ext: over ssh? Because they already have (and will continue to have) valid system shell login, from here it only looks like more admin trouble to setup and maintain pserver, plus it probably reduces the authentication or authorization you had from the ssh and system level, especially when a new pserver hole comes out. How does a hole in pserver reduce security? Is ssh protecting me or not? I realize that all security is additive, but pserver would seem to be no more than paint on the wall of ssh, meaning that if ssh goes down, pserver won't help, but then again it won't hinder either. I have solved most of my admin problem by running admin users as their themselves using $CVSROOT/CVSROOT/passwd entries like this: username:password rather than as the global cvs user: username:password:cvs SNIP Why use the $CVSROOT/CVSROOT/passwd at all, just use the system authentication fallback, it SHOULD make your life easier because only the system level auth files need scrubbed when someone leaves not the system level AND all the cvs repos. The only reason I am using pserver is that it allows my users to have CVAS controlled access to the respositories without giving them dierct write access to them. If you can suggest another way of doing that, I'd be glad to use it. From a security perspective, my understanding is that ssh gives me adequate protection from invasion from the outside world, (ssh is the only port mapped through NAT to the server) and I have not yet identified a need to protect my data from malicious intent from inside, so I'm not really sure what the risks of pserver over ssh really are. As a final disclaimer: I'm an embedded software engineering manager, not a network guru, and the network is a means to an end, not a reason to live, so if I'm missing something, please feel free to snicker and roll your eyes - as long as you then enlighten me as to what I should be doing ;-) Cheers! julian. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Mark D. Baushke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian Opificius [EMAIL PROTECTED] writes: Larry Jones wrote: Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. Yep, that's what I am/was doing. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? Using ssh in a restricted execution mode in general and for restricted execution of CVS is discussed in many places. I suggest you may find more reading useful... try these documents: http://www.idealx.org/doc/chrooted-ssh-cvs-server.en.html http://www.prima.eu.org/tobez/cvs-howto.html http://www.informatimago.com/linux/chrooted-ssh-cvs.html You may also find other documentions via your favorite search engine. Thanks for this input! The problem is that each of these articles achieve their intended results by restricting commands to cvs. I don't want to do that: my CVS users are my engineering department members with legitimate logins. It's only access to the CVS repositories that I have to control. PServer through ssh does exactly what I want in that regard. I have solved most of my admin problem by running admin users as their themselves using $CVSROOT/CVSROOT/passwd entries like this: username:password rather than as the global cvs user: username:password:cvs The only problem now is that if a cvsadmin user introduces a directory into the cvs repository using add, the directory is owned by him, not by the global cvs user, and nobody else can check into/out of that directory. How do I automatically force new directories created by the cvs server to be owned by the global cvs user, rather than the effective user? Maybe there is a Linux feature - something akin to setuid - that operates on the top level repository directory? julian. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Mark D. Baushke wrote:
The only problem now is that if a cvsadmin user introduces a directory
into the cvs repository using add, the directory is owned by him, not
by the global cvs user, and nobody else can check into/out of that
directory.
How do I automatically force new directories created by the cvs server
to be owned by the global cvs user, rather than the effective user?
This is the wrong question.
why is that? Maybe I should be talking group here not owner?
You could have the directories all be in a 'cvs' group and use
find $CVSROOT -type d -exec chgrp cvs g+s {} \;
find $CVSROOT -type d -exec chmod g+s {} \;
The cvs user could belong to this group 'cvs' as well as your admin
users. New files and directories created will inherit the groupid of the
parent directory. A crontab job could go thru and change the ownership
of the files and directories in the tree to that of the 'cvs' user on a
periodic basis as additional cleanup if desired.
g+s is not a valid arg for chgrp. what did you really mean here?
my admin users do already belong to the cvs group, as do all the
repository directories.
I think what you're effectively saying here is that by setting sticky on
the directories, then new directories are created group cvs, and owner
is not important. Is that right?
j.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: I just instigated admin controls by opening up and configuring the UserAdminOptions setting. My account is a member of Linux cvsadmin group, yet like non-privileged users I cannot execute admin commands. Then you're not really a member of the cvsadmin group. If you just added your account to the group, you have to log out and back in again before it takes effect. The id command will show you which groups you're really a member of. That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. julian. = -Larry Jones Girls are so weird. -- Calvin tell me about it - I've married three of them so far ... ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. In that case, my guess is that you're not using your account, you're using the generic cvs account (you say all of your CVS users are mapped to the same cvs system user and it's the system user that has to be in the cvsadmin group). Mapping all of your CVS users to the same system user destroys any system-level security or accountability since everyone appears to be the same user. If you have SSH access to the system, you're much better off using it directly in :ext: mode as individual system users rather than tunnelling pserver and mapping everyone to the same user. -Larry Jones I'm not quite sure what you mean by mapping users. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. I need Internet access, which is why I tunnel across ssh. The instructions I followed to configure cvs suggested I use a userlogin:password:cvsaccount structure to the $CVSROOT/CVSROOT/passwd file, so each user would have his/her specific cvs-related privileges, but that the server would run as user cvs. If I'm not understanding this correctly, please let me know :-) j. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. Yep, that's what I am/was doing. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? j. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Problem with admin privileges
I just instigated admin controls by opening up and configuring the
UserAdminOptions setting.
My account is a member of Linux cvsadmin group, yet like
non-privileged users I cannot execute admin commands.
my error message is:-
cvs [admin aborted]: usage is restricted to members of the group cvsadmin
Yet as I said, I am a member of that group.
What am I doing wrong, please?
My config is as below, and general access works fine.
cvs-1.12.9-2.2 on Suse 9.2
wincvs 2.0.0.2 via :pserver: tunneled through ssh (PuTTY)
$CVSROOT/CVSROOT/config contains:
SystemAuth=yes
UserAdminOptions=km
$CVSROOT/CVSROOT/passwd file entries look like this:
user_name:password:cvs
all cvs repository directories files are user/group cvs:cvs
/etc/xinet.d/cvs is this:
service cvspserver
{
socket_type = stream
protocol= tcp
wait= no
user= root
server = /usr/bin/cvs
server_args = -f --allow-root=/usr/local/cvsroot
--allow-root=/usr/local/vendoroot pserver
}
Thanks for any help.
--
Julian.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
