[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PAM authentication patch - v2

From: Brian Murphy
Subject: Re: PAM authentication patch - v2
Date: Tue, 15 Apr 2003 23:12:05 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1

Mark D. Baushke wrote:

You may need to consider the folks that have enabled the SETXID_SUPPORT
option when building their cvs executables. I have not looked at that
code in some time, but if you choose to add PAM support, you must also
consider these kinds of odd configurations and how they impact your
security model.
What does this do?

...unless you can somehow find a way to have cvs elevate your privilege
level for you... possibly due to odd configuration or installation
choices on the part of the admin installing cvs.
One can always make any program installed by root give anyone root access. You
can't legislate for stupidity.

There has been some discussion of PAM service names on the
openssh-unix-dev list. There was a big stink about "ssh" as used by
a debian patch and "sshd" as used by other folks.
Had a look at this and it doesn't look like they have any serious problems.

Granted this is using a long running root daemon, but it would seem
to be a parallel to the :pserver: method and learning from those who
have been thru this particular nightmare may be useful.
Doesn't seem to be too nightmarish to me, just bugs and fixes like any

It may also be possible to look at the PAM code in openssh 3.6p1 and see
how they are doing things in a 'portable' manner to a number of
different systems.

Looks like what I do, all very standard - the ssh code is much more complex

All that said, I am concerned that addin PAM support is likley to be
more trouble than it is worth.
To whom?

I am pragmatic enough to not be willing to yank :pserver: mode which
should only be used in a secure intranet. Cleaning up problems in the
password code the pserver path takes is a fine idea.

The idea that someone might be having a trivially hashed copy of their
real login password stored into ~/.cvspass strikes me as an extremely
bad idea. If a user only gets their 'cvs password' compromised it is not
necessarily as bad as losing the 'login password' used for other purposes
on their network.
Most people probably have a non-password protected private ssh key in their ~/.ssh directory too. The cvs passwords are stored so that only the user can read/write them.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]