Problems with permissions on sockets.

[Jonathan I. Kamens]

  (Note the Followup-To and cross-posting -- no offense intended, but if
this had been a wizard-level question, the original poster would have
understand what was going on.)

In article <1990Jul26.102810.4816 at hod.uit.no>, arneme at birger.uit.no
(Arne Munch-Ellingsen) writes:
|> The permissons on the device files /dev/kmem and /dev/mem was
changed
|> from 644 to 640. This resulted in that users running programs
opening
|> and reading either kmem or mem complained about it not working. 

  As someone already pointed out, having /dev/kmem and /dev/mem
world-readable is a serious security hole (i.e. "all bets are off"), and
my guess is that someone at your site who is concerned about security
changed the permissions on it.  As someone else has also already pointed
out, systems which are concerned about security should make the
permissions on /dev/kmem and /dev/mem 640, assign group kmem to them,
and make all system programs (netstat, pstat, ps, etc.) setgid kmem.

|> At the
|> same time users started complaining about that rsh and rlogin was
not
|> working properly. The following error message occured:
|> 
|> rcmd: socket: Permission denied
|> 
|> Does anyone know what this means, and how to fix it? Has anyone
|> experienced this happening on their machines, and what is causing
it?

  Rsh and rlogin both have to connect to a local socket with a port
number that is less than 1024.  Such ports are "secure" on Unix systems,
which means that only programs with superuser access can connect to
them.  It sounds to me like somebody, either accidentally or
intentionally, turned off the setuid root bits on your rsh and rlogin
binaries.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710