Re: PAM authentication patch - v2
"Mark D. Baushke" <[email protected]>
| Newsgroups | gmane.comp.version-control.cvs.bugs |
|---|---|
| Message-ID | <[email protected]> |
Brian Murphy <[email protected]> writes: > Mark D. Baushke wrote: > > >I guess that I really do not understand why :pserver: needs to use PAM > >authentication. I am not saying there is not a reason, I just have not > >understood it. > > One good reason is that you want to use LDAP or NIS authentication but > you dont want local shell users. Local shell users can do very stupid > stuff like remove parts of the repository which is not possible via > pserver. Yes, that is a potentially good reason to not allow :ext: to be used. Hmmm... ssh allows for you to restrict remote commands to the 'cvs' command on that server, but that is getting into a bit of an esoteric situation. I can understand where that might be undesirable as a setup, but it would not be that difficult to make a shell that only allowed the cvs command to be executed even for rsh users... there are lots of pages on the net devoted to creation of restricted-shells. (Note: For myself, I actually use a set-gid cvs executable and a repository that has the files and directories owned by an administrative user and no one is allowed in the set-gid group other than the cvs administrator. In practise, it would be possible for someone malicious to mess with the repository during the small period of time when they are doing the commit before the ownership of the files is changed in the log_accum script, but in practice employees who did that would be fired. The mechanism is really only there to try to prevent accidents.) There is still the :gserver: (GSSAPI mechanism) and :kserver: methods (you really do not want to use Kerberos 4 as it is not very secure at all) that might work for you without needing PAM services to be added to cvs. As I understand it, some flavor of Kerberos exists on the recent versions of Windows these days. To be honest, I do not know how well the microsoft and redhat versions of kerberos interoperate. If anyone out there in the reading audience would care to comment on this possibility, that would be interesting information for you to share. Enjoy! -- Mark