"rcmd: socket: Permission denied"

See Signature For Real Name And Email Address

unread,

Jan 31, 1997, 3:00:00 AM1/31/97

to

Here's my situation. Recently, one of our Unixware 1.1 systems was
rebooted and failed to come up on the network. An ifconfig would show
that no network interfaces were configured, not even the loopback
interface.

After poking around for a while, I discovered one damaged executable,
/sbin/creatiadb. On the assumption that damage to other unknown files
was causing the network problem, I decided to try duplicating the root
drive from a similarly configured system. This is a procedure that has
worked well for us in the past since we have 4 of these UW 1.1.4 systems
with nearly identical hardware (same PCI bus, SCSI controller and
ethernet card).

I duplicated the root drive off a running system, installed it on the
busted system, and performed the changes necessary to change the host
name.

All network functions (NIS, the automounter, nntpd server) are now
working correctly on the thus repaired host except for rsh and rlogin.

One of the users brought it to my attention that any attempt to rsh or
rlogin would result in the error:

rcmd: socket: Permission denied

Once I thought I had discovered the problem: by restoring the file
/etc/ioctl.syscon from the old root drive, I was able to do rsh and
rlogin as root, but all other users continued to get the above error.

Anyone know what this is? I suspect there is some one file somewhere
that is not right but can't put my finger on it. I've covered the
obvious things like /etc/passwd, /etc/hosts, /etc/hosts.equiv,
/etc/services, /etc/inetd.conf. I'd sure like to fix one or two files
as opposed to, say, doing a full reinstall.

--
Larry Mulcahy bo...@lucent.com
Computing and Telecommunications Services Unix System Administration Team
Linux: It is now safe to turn on your computer.

Don Lee

unread,

Feb 1, 1997, 3:00:00 AM2/1/97

to

I once had the same problem but was on SCO 3.2.4.2 (not Unixware)
so possibly its the same thing. The problem I had was that the
executables had lost their setuid permission (chmod u+s). Check your
other Unixware systems and see if the permissions of your executables
are are correct.

Don

See Signature For Real Name And Email Address
<alt....@dispatch.demon.co.uk> wrote in article
<uqfohe5...@drmail.dr.lucent.com>...

Tim Rice

unread,

Feb 3, 1997, 3:00:00 AM2/3/97

to

Don Lee (dl...@esd.dl.nec.com) wrote:
: I once had the same problem but was on SCO 3.2.4.2 (not Unixware)

: so possibly its the same thing. The problem I had was that the
: executables had lost their setuid permission (chmod u+s). Check your
: other Unixware systems and see if the permissions of your executables
: are are correct.

: Don

: See Signature For Real Name And Email Address
: <alt....@dispatch.demon.co.uk> wrote in article
: <uqfohe5...@drmail.dr.lucent.com>...

: > All network functions (NIS, the automounter, nntpd server) are now
: > working correctly on the thus repaired host except for rsh and rlogin.

If your on UnixWare, try this.

# filepriv -f dev,filesys,driver /usr/bin/rsh
# filepriv -f dev,filesys,driver /usr/bin/rlogin

: >
: > One of the users brought it to my attention that any attempt to rsh or

: > rlogin would result in the error:
: >
: > rcmd: socket: Permission denied
: >
: > Once I thought I had discovered the problem: by restoring the file
: > /etc/ioctl.syscon from the old root drive, I was able to do rsh and
: > rlogin as root, but all other users continued to get the above error.
: >
: > Anyone know what this is? I suspect there is some one file somewhere
: > that is not right but can't put my finger on it. I've covered the
: > obvious things like /etc/passwd, /etc/hosts, /etc/hosts.equiv,
: > /etc/services, /etc/inetd.conf. I'd sure like to fix one or two files
: > as opposed to, say, doing a full reinstall.

--
--
Tim Rice Multitalents 707 887-1469
t...@trr.metro.net