Sun-Spots Digest, v6n83
William LeFebvre
Sun-Spots-Request at RICE.EDU
Fri May 13 08:41:58 AEST 1988
SUN-SPOTS DIGEST Thursday, 12 May 1988 Volume 6 : Issue 83
Today's Topics:
Administrivia
Re: selection_svc as security hole!
Re: Bug in initgroups
allow NFS filesystems to be exported read-only
Identifying a csh running under NeWS and X
Memory for 4/110's
More getwd problems
Need help with SLIP installation
Info about SunView and External Processors?
How to recognize NFS packets?
Ease on Suns?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Thu, 12 May 88 17:04:36 CDT
From: William LeFebvre <phil at Rice.edu>
Subject: Administrivia
Well, it seems that the three-digests-a-day habit has really helped to
alleviate the backlog. There is, however, an unusual amount of source
still waiting to be inserted in the archives. I also haven't updated the
sun-source index in a long time. If you sent source to me a while ago and
still haven't seen the announcement posted, hang in there. It takes me a
little longer to process those types of submissions. Icons are also
delayed for an unspecificed amount of time (they take very low priority).
I thank you all for your patience. I am beginning to see some light at
the end of the tunnel.
William LeFebvre
------------------------------
Date: 9 May 88 15:14:01 GMT
From: roy%phri at uunet.uu.net (Roy Smith)
Subject: Re: selection_svc as security hole!
Reference: v6n73
In Volume 6, Issue 73, Jeff Glass points out a ghastly security hole
involving selection_svc and gives a 3-liner which pretty much lets anybody
read anybody's else's files. The fix Jeff gives is to make a copy of
suntools called selection_svc to run setuid nobody. While I guess this
would work, people should be aware that it also foils Sun's ugly toolmerge
kludge; the separate selection_svc will not run shared-text with the rest
of the suntools processes, wasting valuable (especially on a 3/50) memory.
Presumably the upcomming shared library support will make toolmerge
obsolete?
Roy Smith, System Administrator
Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy at uunet.uu.net
------------------------------
Date: Mon, 9 May 88 18:59:19 EDT
From: dupuy at columbia.edu (Alexander Dupuy)
Subject: Re: Bug in initgroups
Even before my posting finally(!) appeared in comp.sys.sun, I got the
answer, from Chris Maio, right here at Columbia:
> the "disappearing wheel group" is not a bug in initgroups, but rather a bug
> in the programs (rshd, rexecd, etc) that are calling setgid(2) after calling
> initgroups(3). Simplifying a bit, what happens is that rshd starts up with
> its gid set to 0, initgroups doesn't add group 0 to your gidset because your
> process is currently in group 0, and finally setgid(2) removes you from group
> 0 as a consequence of changing your gid from 0 to whatever is specified in
> /etc/passwd. Doing the setgid before the initgroups solves the problem.
I also received a response from Rayan Zachariassen <rayan at ai.toronto.edu>,
with the same fix, but I think his reasoning as to the nature of the bug
was less accurate.
Since we haven't yet received our sources, I thought I might post a
workaround which eliminates this problem for binary sites:
% ypmatch nobody group # you'll have to add this entry, since
nobody:*:-2: # chgrp -2 file gives "unknown option"
% chgrp nobody /etc/in.rshd /usr/etc/in.rexecd /usr/etc/rpc.rexd
% chmod g+s /etc/in.rshd /usr/etc/in.rexecd /usr/etc/rpc.rexd
% lsl /etc/in.rshd /usr/etc/in.rexecd /usr/etc/rpc.rexd
-rwxr-sr-x 1 root -2 57344 May 9 18:54 /etc/in.rshd
-rwxr-sr-x 1 root -2 54556 May 9 18:50 /usr/etc/in.rexecd
-rwxr-sr-x 1 root -2 73728 May 9 18:50 /usr/etc/rpc.rexd
You don't really need to fix in.rexecd, since no program since 4.1bsd uses
that service, but it doesn't hurt. Note that now the problem with the
wheel group exists with the nobody group, but that shouldn't be a real
inconvenience. Since all these programs expect to be running as root, and
call setuid() and setgid() before they do anything serious, making them
setgid is not in any way a security loophole.
@alex
--
inet: dupuy at columbia.edu
uucp: ...!rutgers!columbia!dupuy
[[ I later received this message from Mr. Dupuy: --wnl ]]
oops! well, I had tested my workaround with on, and it worked, but it
doesn't seem to fare as well with rsh. Perhaps someone with sources could
send in a patch for rshd?
@alex
inet: dupuy at columbia.edu
uucp: ...!rutgers!columbia!dupuy
------------------------------
Date: 5 May 88 20:15:43 GMT
From: Jeff Glass <jjg%linus at mitre-bedford.arpa>
Subject: allow NFS filesystems to be exported read-only
Run the following program on an NFS server, and it will modify the vfs
structure of a filesystem so that NFS clients cannot modify the
filesystem. (Any attempts to do so fail with errno = EROFS.) I have
included an adb script that the program uses to print out the vfs
structure. Change the definition of the program's print_vfs_command
variable according to where the script is put.
----- cut here -----
# to unbundle, sh this file.
# files: vfs change_nfsro
echo 'vfs'
/bin/sed -e 's/^X//' > 'vfs' << 'End of vfs'
X./"next"16t"op"16t"vnodecovered"16t"flag"n4X
X+/"bsize"16t"exroot"8t"exflags"8t"data"nD8+dxX
End of vfs
echo 'change_nfsro'
/bin/sed -e 's/^X//' > 'change_nfsro' << 'End of /guru/jjg/bin/change_nfsro'
X#! /bin/csh -f
X#
X# Jeff Glass, The MITRE Corporation, Thu May 5 15:38:32 EDT 1988
X#
X# this program sets the read-only and exported flags for a NFS filesystem on
X# the NFS server, so that no client can modify the filesystem, regardless of
X# whether the client mounts it read-only or read-write. the server can mount
X# it read-only or read-write independent of this. this program was inspired
X# by reading the file sun/sys/nfs/nfs_server.c.
X#
X# usage: change_nfsro [-w] [-k vmunix] [-o roopt] fsys1 [fsys2 ...]
X# -k: pathname of kernel. default: /vmunix
X# -o: option flag. one of: rw, ro. default: ro.
X# -w: do the operation. default: just print what would be done.
X#
X# this program is known to work under SunOS 3.5. you must run the program
X# on the NFS server and have write permission on /dev/kmem in order for it
X# to work.
X#
X# since modifying the kernel through /dev/kmem is inherently risky, I
X# suggest that you run change_nfsro once without the "-w" flag, just to
X# see what it will do. examine the field labeled "op"; the value of this
X# field should be the value of the kernel variable "ufs_vfsops". run
X# "nm /vmunix | grep ufs_vfsops" and check. examine the bsize field;
X# the value of this field should be some power of 2, such as 8192.
X# examine the exflags field; the value of this field should be 0 or 1.
X# once you are satisfied, then run change_nfsro again with the "-w" flag
X# to make the change. caveat emptor.
X#
Xset noglob
Xalias stderr '/bin/sh -c "cat 1>&2"'
Xset name = $0
Xset name = $name:t
X
Xwhile (1)
X switch ( _$1 )
X case _-- :
X shift
X break
X breaksw
X case _-k :
X set kernelpath = "$2"
X shift; shift
X breaksw
X case _-w :
X set adb_args = "$1"
X shift
X breaksw
X case _-o :
X set ro = "$2"
X shift; shift
X breaksw
X case _-* :
X stderr << END
X${name}: unrecognized option: $1
X${name}: usage: $name [-w] [-k vmunix] [-o roopt] fsys1 [fsys2 ...]
X${name}: roopt is one of: rw, ro.
XEND
X exit 1
X breaksw
X default:
X break
X breaksw
X endsw
Xend
Xif (! $?kernelpath) set kernelpath = /vmunix
Xif (! $?adb_args) set adb_args
Xif (! $?ro) set ro = 1
Xif ($ro:q == ro) then
X set ro = 1
Xelse if ($ro:q == rw) then
X set ro = 0
Xelse if ($ro:q <> 0) then
X set ro = 1
Xendif
X
X# these constants are obtained through inspection of "../ufs/mount.h"
Xset sizeof_mount_entry = 28
Xset offset_vfs = 0
Xset name_mount_table = mounttab
X# these hex constants are obtained through inspection of <sys/vfs.h>.
Xset mask_export = 10
Xset mask_ro = 1
X# misc constants
Xset print_vfs_command = '$</guru/jjg/bin/lib/adb/vfs'
X
Xforeach fsys ( $argv:q )
X set foff = `df -t 4.2 | awk \""$fsys"\"' == $1 || '\""$fsys"\"' == $(NF) {printf "%d\n", NR-2}'`
X @ koff = $foff * $sizeof_mount_entry + $offset_vfs
X adb $adb_args $kernelpath /dev/kmem << END
X$name_mount_table+0t$koff/X
X<0$print_vfs_command
X$name_mount_table+0t$koff/X
X<0+0t12/X
X./W<0&~$mask_export+$mask_export
X.+0t18/x
X./w<0&~$mask_ro+$ro
XEND
Xend
End of /guru/jjg/bin/change_nfsro
------------------------------
Date: 9 May 88 06:51:26 GMT
From: mkhaw at teknowledge-vaxc.arpa (Mike Khaw)
Subject: Identifying a csh running under NeWS and X
Reference: v6n73
> I would be interested in knowing what people do to unambiguously identify
> a csh running under X or NeWS.
My guess:
NeWS uses the env. var. FRAMEBUFFER
X uses the env. var. DISPLAY
BTW, WINDOW_ME is not defined for a shell script that runs without a
window (e.g., from the rootmenu so it's not a reliable way to tell if
suntools is running (as I mentioned in a previous posting). Sun s/w
support says that WINDOW_PARENT is defined for every process that runs
under suntools.
Mike Khaw
internet: mkhaw at teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: 9 May 88 09:24:03 PDT (Monday)
From: "Thomas_D._Herbst.HENR801c"@xerox.com
Subject: Memory for 4/110's
Reference: v6n70
In Sun-Spots Digest, v6n70
darrell%cs at ucsd.edu (Darrell Long) writes
>Hello. I am trying to decide whether I should get a 4/110 or a 3/60 with
>lots of memory. My work is very CPU and memory intensive. I have heard
>that the 4/110 is fixed at 8meg, and cannot be expanded -- is this true?
>What about software: are there any special problems that I should know
>about with the 4/110?
I recently placed an order for serveral 4/110's, and we also require more
than 8M. What Sun has done to try to save sales in the face of memory
wars is to use the more readily available 256k simms in slots that will
accept 1M simms. Clearpoint (and other companies soon, I'm certain) is
going to be offering the 1M Static Column D-Rams (being a s/w person, I
don't know what Static Column D-Rams are, but they aren't what is in your
3/60). Clearpoint seems to be looking at about $500-$600/M puchased in
quantities of 8M. There is some indication that you can mix types so you
could have 8M of 1M simms and fill your other slots with 256k simms for a
total of 12M. I am not certain that will work, but have been lead to
believe that it may. Regarding your 3/60 vs 4/110 question - I am keeping
my 3/60 because more software is available for it. I will open windows to
a 4/280s and other local 4/110's for crunching. Xwindows/NeWS will
facilitate that. Other problems - SPARC objects require significantly more
storage space than the same code in 68020. It can be as much as 40% more.
tom
Disclaimer -
This isn't a Clearpoint ad, they are the only company that I know of that
has publicly offered extra memory for the 4/110.
------------------------------
Date: Mon, 9 May 88 09:02:46 PDT
From: frame!troy!drf at sun.com (David Fuchs)
Subject: More getwd problems
While we're complaining about getwd, here's my favorite problem:
me% su
me# mkdir /tmp/foo
me# chmod 000 /tmp/foo
me# mount you:/usr/you /tmp/foo
me# ^D
me% cd /tmp/foo
me% ls -a
. .. [...other stuff...]
me% pwd
pwd: getwd: can't open ..
It seems that the nasty permissions of the mount point cause getwd to
become confused. In all other respects, the original permissions of the
mount point seem to be completely insignificant, having been (correctly)
superseded by the permissions of the mounted stuff.
[[ The manner in which getwd finds the name is repulsive to me. It seems
like its too much work. But I guess it's the price you pay to have files
separate from file names. --wnl ]]
------------------------------
Date: Mon, 9 May 88 08:10:48 EDT
From: oravax!alex at cu-arpa.cs.cornell.edu (Alex Feldman)
Subject: Need help with SLIP installation
I tried to install the version of SLIP that I got from the archive server
(on a diskless 3/60) and while the new kernel boots with no trouble, when
I try to run slattach I always get the error:
ioctl(TIOCSETD): No such device or address
Anyone know what I'm doing wrong?
Alex Feldman
oravax!alex at cu-arpa.cs.cornell.edu (ARPANET)
...{rochester,allegra}!cornell!oravax!alex (UUCP)
------------------------------
Date: Thu, 5 May 88 09:40:16 PDT
From: ucla-cs!cepu!ashtate!trwrb!trwspf!bebop at ucbvax.berkeley.edu (A. Takatsuka)
Subject: Info about SunView and External Processors?
Can anyone give me information concerning the use of external processors
on a SUN workstation under SunView? Specifically, I would like to talk to
a transputer system sitting on the VME bus. Also, I am interested in the
pros and cons of using NeWS vs. SunView when interfacing to an external
processor, if there are any.
Allen M. Takatsuka - (213) 535-3785
TRW, One Space Park O2/1779, Redondo Beach, CA 90278
bebop%trwspf at brand.usc.edu
bebop%trwspf at trwrb.trw.com
bebop at trwspf.trw.com
{sdcrdcf,scgvaxd,ucbvax,decvax}!trwrb!trwspf!bebop
------------------------------
Date: 10 May 88 00:55:06 GMT
From: cyrus at hi.unm.edu (Tait Cyrus)
Subject: How to recognize NFS packets?
I am trying to figure out how to interpret UDP port numbers. After
watching packets fly around, I have several questions:
1) How can you tell if a UDP packet is an NFS packet? I
know that NFS is supposed to use port number 2049,
but why is it that 2049 always seems to be matched
with port 1023, 1022, 1021,.....? Is this because
a server typically has several NFS daemons running?
2) How does NFS initiate a connection? Does a 2049/1023
packet fly by containing the "real" src/dst port
numbers of the NFS connection because I saw A LOT of
UDP connections that only use 1 packet?
3) Why are there so many packets with src ports and dst ports
of zero (0). During a 30 minute `watch' of the net between
one server and six clients I saw 158167 total packets. Of
these, 4% (6740) were UDP packets with both the src and dst
ports = 0. This is NOT the total seen with src & dst = 0,
but just that seen between two machines (client/server).
Below is a short excerpt from my net monitoring. Note the lines I have
marked with a *:
08:00:20:01:84:b3 08:00:20:01:7f:4a 38962(24.63%) packets, 42607004(29.43%) bytes
IP packets = 38962
ND packets = 22026
UDP packets = 16936
* dst port 2049, src port 1023, 129.24.24.152 <- 129.24.24.5. packets = 2996
* dst port 2049, src port 1022, 129.24.24.152 <- 129.24.24.5. packets = 44
dst port 4, src port 48010, 129.24.24.152 <- 129.24.24.5. packets = 8
dst port 0, src port 56768, 129.24.24.152 <- 129.24.24.5. packets = 11
dst port 3, src port 50348, 129.24.24.152 <- 129.24.24.5. packets = 14
dst port 3, src port 23474, 129.24.24.152 <- 129.24.24.5. packets = 1
dst port 1, src port 62652, 129.24.24.152 <- 129.24.24.5. packets = 4
* dst port 0, src port 0, 129.24.24.152 <- 129.24.24.5. packets = 6740
* dst port 0, src port 1, 129.24.24.152 <- 129.24.24.5. packets = 669
Any help that you can provide me would be greatly appreciated because I am
having a terrible time trying to figure out how UDP port numbers are used.
W. Tait Cyrus (505) 277-0806
University of New Mexico
Dept of Electrical & Computer Engineering
Parallel Processing Research Group (PPRG)
UNM/LANL Hypercube Project
Albuquerque, New Mexico 87131
e-mail:
cyrus at hc.dspo.gov
------------------------------
Date: Mon, 9 May 88 21:57:03 EDT
From: jsol at bu-it.bu.edu
Subject: Ease on Suns?
Has anyone successfully ported Ease (the Sendmail cf file
compiler/language) to Sun O/S 3.4 (or better?)..............
thanks,
--jsol
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list