News Group Posts

OSR5 ssh get proper libsocket for

Caldera's OpenSSH 3.4p1 package chroot

Subject: Re: libsocket.so.1
From: brian@aljex.com (Brian K. White)
Date: Tue, Feb 11, 2003 5:42 AM

Jean-Pierre Radley <jpr@jpr.com> wrote in message news:<20030211023047.GA17015@jpradley.jpr.com>...
> Brian K. White typed (on Mon, Feb 10, 2003 at 05:26:17PM -0800):
> | I now have a script that will do everything for you to install
> | Caldera's build of OpenSSH 3.4p1 on Open Server, and it works on all
> | of 5.0.4, 5.0.5, and 5.0.6
> |
> | In the case of 5.0.4, where you need to replace your libsocket.so.1
> | with one from a 5.0.5 box...
> 
> Why do you want to do that, instead of compiling against libsocket.so.2?
> SCO has provided libsocket.so.2 in several security patches and/or other
> supplements for 5.0.4, 5.0.5, and 5.0.6.
> 
> The binaries at ftp.jpr.com are of OpenSSH 3.5p1, not 3.4p1, and are
> compiled against OpenSSL 0.9.7 and use libsocket.so.2.

I compiled from more recent source too, and I always have
libsocket.so.2 installed too, and in fact this script even always
installs it, but the SCO-built package doesn't happen to be linked
against it. I wanted to have a one-button script that installed
whatever the Latest version was that SCO themselves supplied, because
as long as their version was current, I would prefer to install that,
if I could script-away all the manual time-consuming steps. I did, and
it was great, but the 5.0.4 install still left a bit to be desired. I
finally figured out a way to make the 5.0.4 install complete, by
extracting the library from rs505a and I just wanted to make my script
complete now that I *could*. Plus a working script also serves to
document a procedure that may not get performed often enough to keep
all the details in active memory (in this case, not only to install
openssh from sco, but also how to extract a specific file from a
cpio-format vol file). And it makes a good answer to a faq.

I will probably start installing from a 3.5p1+chroot tar of my own
from now on instead of this script, once I create a better tar in the
first place, but I used this script exclusively for about the last
year to very quickly install openssh on new and old boxes with no
effort, since it automatically handles the requirements as well as
openssh itself. It runs custom non-interactively so when I run the
script, all I do is watch the stuff scroll by except for one spot
where the installation of prngd requires me to make up a password for
the user prngd it creates. The second the script is done, I can log in
to the box via ssh, and it's also already been added to the startup rc
scripts.

It'll be a little while yet before I have a script that is that
complete that installs from my own tar of a newer build instead of the
sco-built vol package.

the only reason I'm only using either sco's or mine and bypassing
yours, is that I like the chroot patch. I only really *need* it in one
situation so far, but it just makes sense to me to have the option all
the time. I have read some of the arguments on the ospenssh-devel mail
list archive from developers who think it's a bad idea and that you
should just chroot the whole sshd process instead of teaching ssh
itself how to chroot a sub-process, but any time I want to use the
chroot ability, I specifically want to minimize the amount of stuff
that I have to put in the chroot tree in order for the system to work.
For sftp-only accounts, I'd really like something that has been
mentioned but I don't think done, which is go a step closer and teach
sftp-server how to chroot, instead of putting sftp-server itself and
all it's support libraries within the chroot tree seen by the user.
then the sftp-only user would really see only their own files, not
even the minimal /etc /lib & /bin would be necessary.


> | While was updating this script and searching for publicly downloadable
> | copies of libsocket.so.1 I found *2* different libsocket.so.1's
> | in rs505a, and I was wondering if anyone could tell me what the
> | difference is (other than the obvious size and path)
> 
> The variants in /usr/lib/libp are profiled libraries.  "man cc" says:
> 
>     DIR/libp
>               subdirectory of each LIBPATH entry in which to check
>               for profiled libraries

ahh got it. that explains why the file itself was over twice as big
too.
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.