[Bug 131] Problems with sshd's compiled in default PATH.

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=131





------- Additional Comments From smithj9870 at yahoo.com  2002-03-02 08:07 -------
> 1.  --with-default-path  will disable OpenSSH adding in the $PREFIX/bin (we 
> assume that since you are smart enough to set your own default path, you will
> be smart enough to know where you are putting scp).

That will only solve one of the problems, having the incorrect path compiled
into the sshd binary, not how sshd will be able to find scp if it has been moved
or installed somewhere unusual.

> 2. 'subsystems' vs 'remote exec'.  Use the right terms if you are going to 
> argue for including a feature.  Otherwise it makes you look like you've not 
> bothered to learn the product.

I am not responsible for your misunderstanding me and going on a rant.  Maybe I
should have been a little more clear, but you do not have to assume I mean
something else by subsystem and imply that I am an idiot.

> No, I still don't feel this is a security hole unless you are doing stupid
> things like --with-prefix=/home/user/  while building your package.  And if
> you are then we can not do much stop you from doing stupid things. =)

That path was just an example.  Just because you can't think if a way to take
advantage of a vulnerability doesn't mean the current method is 100% safe.  Also
try to remember that not everyone installs software in the "standard" places,
some sites might have other requirements.  Do you agree that a system with the
smallest number of vulnerabilities is more secure?  Why would you advocate
adding a directory to the path just so a daemon can find one file?  Is that
really being minimal?

> And I have nothing against something called 'DefaultPATH'.. I do have
> something against people shouting the sky is falling.  As I said.. drop the
> 'It is a security issue', provide a patch, and show that /etc/profile,
> /etc/ssh/enviroment, etc are not valid generic solutions.

So I guess no one ever uses ssh to login as root to do remote system
administration then?  You know for sure that there is absolutely no security
risk with the current design then?  And root doesn't have to worry about what
sshd decides to stick in it's path just because it thinks scp is somewhere? 
Like I said before, the simplest and correct solution is to have a config option
that tells sshd where scp is, instead of adding another directory to the path
that the user might not need.  This might not be a problem if ssh is being
installed in a usual place like /usr or /usr/local, but try to think of the more
general case where some site decides to install it somewhere you never thought
of.  /etc/profile is NOT the appropriate place to put this path, it is only an
ugly kludge to fix the real problem, especially when it might only be needed so
sshd can find one thing (scp).  Why should the sys admin have to add that path
to the general system shell config scripts, and have to make sure all possible
scripts are correct, just because sshd can't find something without it?  It
should be the responsibility of sshd to configure this since it needs to know
about it.  And about patches, tell me why I should waste my time writing a patch
when my suggestion has been shot down from the very beginning and negatively
criticized over and over.  If you want people to contribute patches to an
opensource project then you should have an open mind and treat them with
respect.  Again, try to look at the more general case, not just the "normal"
install everything in /usr case.  I think you will see that the current design
is not the best possible one.

> Relocatable packages are problematic at best depending on the web of 
> dependancies.

I know about the problems with relocatable packages, but ssh is fairly simple,
just a few executables, some documentation and a few config files.  Built
correctly, it should be easily relocatable except for one or more of the config
files.

~Jason




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.