Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to email@example.com.
Tony Hoyle wrote: > :local: is not always admin, but they are always the same as the logged > in user (ie. you can't change username). What it does do is bypass > repository registration by using absolute paths instead of aliases - > fixed in evs (so local behaves exactly like all other protocols now). Don't forget that TCVS uses in the "ultra simple" single person just-getting-started case, the local protocol to a repository on the user's HDD. It makes sense in that case to use the repository there. Also, local is used to INIT the repository. Some issue is that the user can use :local: without the :local: part, just implicitly, so they don't know what they are doing. I can't see an easy fix for that though. Not sure what my point is here... > On Unix we could check/set the permissions of the cvspass file better > (should be rw to owner only and enforced as such) but it's no less > secure than ssh+certificates given that caveat. Passwords embedded in the CVSROOT is far worse than the .cvspass file... I agree that the .cvspass should be set up owner only. On Win, the user reg is private anyway (and passwords scrambled a bit at that). In either case it would require a compromised machine to obtain the passwords. IMHO I don't think that the login should be restricted to any particular protocol. Now, if you're thinking about implementing something like a policy file for the workstations in a corporate environment to restrict behavior, I could certainly support that (provided we had a customer who needed it). > > The threat model is based on the idea that the client is secure but bad > guys can sniff the link. If you define a threat model where the client > is compromised we have to design a whole new system of login. cvsagent > goes some way to handle it but doesn't really address that scenario > directly (but even that needs timeouts to be truly useful - it should > ditch the stored password after 5 minutes or so to avoid the 'hacked > during lunch break' scenario). Ticking the "lock workstation" on the screen saver options would be more secure. "Hacking during the lunch break" opens up many more ways of obtaining the passwords than cvsagent could possibly protect against. >> The question is - how much do we inconvenience the experienced people >> for the sake of the new users/people who jump to (incorrect) >> conclusions? >> > We need to push people more towards sspi and ssh, and make pserver a > last resort option somehow - but I haven't thought of a way that'll do > that without creating huge amounts of support requests. sserver too! > It's also possible there's a case to disable support for non-system > users. This would eliminate the CVSROOT/passwd file which is a source > of some confusion. And make ACLMODE=Normal the default sometime (which > IMO is why people get the idea that ACLs don't work, because by default > they work in an opposite fashion to system ACLs). Hmmmm. A config option that more clearly sets the preference would be good, e.g. USER_DB = system_only | passwd_only | both, defaulting to system_only. > > Whether this belongs in a stable tree though is debatable. Maybe at the next major rev, but certainly not in the 2.5.03 or 2.5.04 series. Regards, -- Glen Starrett Technical Account Manager, North America March Hare Software, LLC http://march-hare.com/cvspro/