Jeremy Pereira wrote:
> On 23 Aug 2006, at 20:53, Nico Kadel-Garcia wrote:
>
>>
>>
>>>
>>> On 23 Aug 2006, at 11:30, Nico Kadel-Garcia wrote:
>>
>>>> Well, true. It's most easily enforceable on machines where I'm
>>>> the sys-admin, and could put my copy in /usr/bin or /usr/local/bin.
>>>
>>> PATH=$HOME/unauthorisedsvn/bin:$PATH
>>> export PATH
>>> svn ....
>>
>> Again, true. They could also create a .login message that says "My
>> Password is: XXXX".
>>
>> But there's a practical distinction between leaving the passwords
>> lying around by default in a well-known, accessible space (and
>> having permissions of 700 is still pretty accessible, especially in
>> an NFS home directory environment or a laptop or unencrypted backup
>> environment!), and in leaving user's enough room to hang themselves
>> if they really insist.
>>
>
> Talking specifically about your modified svn which does not store
> passwords, an effect of that would be your users having to type their
> passwords in lots of times which some of them might find irritating.
> It's quite conceivable that some of them would discover the
> subversion web site and download the unmodified software. It's far
> less likely that they would deliberately echo their password to the
> terminal whenever they logged in.
Oh, goodness, no. ssh+svnserve will still work using normal SSH based
keychains or ageits, as will web access that has a separate key storage
method. It's the built-in svnserve or HTTP built-in clients for subversion
that store the passwords in clear-text: The point would be to keep the
*default* subversion client from being used with its poor model for client
security.
> You could, of course, change the client config file to not store
> their password and then explain to your users why you have done it.
> That'd probably stop them from changing it back.
Yeah, that's an approach. It requires patching a lot of accounts and
modifying people's files in them, though, rather than keeping control of the
system binaries.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 24 12:34:21 2006