Andrey Aristarkhov wrote:
>>-----Original Message-----
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
>>
>>
>Of
>
>
>>Derek Robert Price
>>
>>
>Yes, I use local repository for development.
>I did not make any changes to server.c, but 'cvs user|password' works in
>pserver mode: I've made corresponded tests. Telling the true, I don't
>understand _why_ it works, but it _do_ works. Even if server.c will need
>patches, they are trivial.
>
>
I'm fairly certain that is impossible. Did you test against a server
running on the same machine? Or perhaps the same path found the
repository on a network drive from your server and from your client?
>>I don't think I'd add this change without it working with remote
>>repositories. First of all, the security is trivially easy to break -
>>if the CVS executable can change the files, so can the user, either by
>>hand or by downloading an older version of CVS and using that.
>>
>>
>Second,
>
>
>>everything that CVS can do should work in both modes, as
>>indistinguishably as possible.
>>
>>
>I've already mentioned, that pserver mode is supported. It's absolutely
>transparent for user which mode is used - local or pserver.
>You are right about security triviality. But this is that case where OS'
>permissions can help.
>
>
Hrm, ok, though I still don't believe you were really running in
client/server mode. And the ineffective password verification probably
shouldn't be bothered with in local mode. Not unless CVS is hacked to
run setuid in local mode and I'm fairly sure there'd be pretty general
opposition to that. More later.
>My idea of 'accessinfo' file is similar you've described one above. You
>place filter script (plugin) into accessinfo and lookup result of its
>execution. Actually the script could use any mechanisms to make a
>decision to grant or deny access (for example, by means of contacting
>CORBA-server or Directory-server). I believe that implementation of this
>plugin mechanism is much easier and compact than XMLRPC or any other
>ones.
>
>
Hrm. Maybe, but we should discuss this in a seperate thread. It's
confusing the discussion of your passwd and user patches.
>Can we make sub-namespace 'user' of 'cvs admin'? In this case I can
>quickly incorporate user.c's logic into admin.c. In this case cvs
>command will look like 'cvs admin user ...'. I can suppose, that it will
>be more convenient other than using different options.
>
>
This is exactly what I was imagining.
>>I think you're right, but I'd still like to see it use the same
>>`cvsadmin' group or not work at all.
>>
>>
>If user will be in admin command namespace, I think it should use
>'admin's access restrictions.
>
>Regards,
>Andrey
>
>
That would be simplest I think. And it doesn't add more security code
to CVS. Again, I'll discuss the ACL plugin in a separate thread, but
the general principle with CVS has been to avoid new security code based
on the fact that security requires security audits and the like and we'd
like to leave that kind of thing to someone else with more resources and
people who are good at it, the OS or SSH, for example. PAM might be
okay, but that's a discussion for a separate thread as well, I think.
There's still the issue of an NT server, but that exists regardless and
can be solved separately.
Derek
--
*8^)
Email: [EMAIL PROTECTED]
Get CVS support at http://ximbiot.com
--
OPHELIA
O, what a noble mind is here o'erthrown!
The courtier's, soldier's, scholar's, eye, tongue, sword,
Th'expectancy and rose of the fair state,
The glass of fashion and the mould of form,
Th'observed of all observers, quite, quite down!
And I, of ladies most deject and wretched,
That sucked the honey of his music vows,
Now see that noble and most sovereign reason
Like sweet bells jangled, out of time and harsh,
That unmatched form and feature of blown youth
Blasted with ecstasy. O, woe is me
T'have seen what I have seen, see what I see!
- Hamlet, Act III, Scene 1, Lines 151-162
_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
