[EMAIL PROTECTED] on 2000.07.22 09:07:59
>>>>>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>NLY> over to the server for its use. Server CVS will still run as the
>NLY> server user but will record the client username within its logs.
>NLY> For example, if I am nyap on the client and I set
>NLY> CVSROOT=cvsuser@cvsserver:/home/cvsgroup/.cvsroot, I will be
>NLY> cvsuser on host cvsserver, but CVS will know me as nyap (ie it'll
>NLY> log my actions as nyap).
>
>Wouldn't it be slightly more convenient if you would have to set
>
>CVSROOT=nyap@cvsserver:/home/cvsgroup/.cvsroot
>
>and let the server itself think about cvsuser?
No, doing so would require sysadmin involvement each time another user needs
access (or needs to be denied access) to the repository.
Like I said, CVSROOT=nyap@cvsserver:/home/cvsgroup/.cvsroot is the preferred way
to go. You get no argument from me there, but there are environments that have
other requirements. Otherwise, why allow pserver to map many users to one.
>NLY> Now, about security, cvsuser will need access to the repository.
>NLY> nyap will need valid keys to become cvsuser. If nyap gives those
>NLY> keys away, others will be able to act as cvsuser (unless the keys
>
>If nyap gives those keys away, others should be able to act only as
>nyap. If single cvs user compromise compromises entire repository --
>that's not an option.
>
>And I propose that if nyap has valid keys, he will become nyap, and
>not `cvsuser' or anything else. This simplifies things a lot.
>Surely, he _will_ become `cvsuser' on server machine, but we just
>don't think about it now...
This is my point exactly. Those wishing something very secure should not use a
many-to-one mapping of users. Those that trust their developers can get away
with some security flaws in the repository.
>NLY> are limited to use by nyap (SSH currently doesn't have such an
>NLY> option 'cos the server can't guarantee that the username info
>NLY> sent by the client is valid)).
>
>I have to study ssh manuals to competently speak about `keys', as I
>effectively almost always speak about `passwords'. Sorry, maybe then
>I will change my mind.
Fair enough.
More or less, though, keys and passwords are the same thing -- they're meant to
authenticate users (or, at least, authorize them for login or other actions).
The feature of SSH I was getting at is missing since it is impossible to
guarantee its validity (although, somehow, you can get the use of a key
conditional on the client ip address (IMHO, it should also be impossible to
guarantee this info)).
Noel
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
