Sun-Spots-Request@RICE.EDU (William LeFebvre) (05/13/88)
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@rice.edu Send subscription add/delete requests to: sun-spots-request@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@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@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@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@uunet.uu.net ------------------------------ Date: Mon, 9 May 88 18:59:19 EDT From: dupuy@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@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@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@columbia.edu uucp: ...!rutgers!columbia!dupuy ------------------------------ Date: 5 May 88 20:15:43 GMT From: Jeff Glass <jjg%linus@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@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@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@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@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@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@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@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@brand.usc.edu bebop%trwspf@trwrb.trw.com bebop@trwspf.trw.com {sdcrdcf,scgvaxd,ucbvax,decvax}!trwrb!trwspf!bebop ------------------------------ Date: 10 May 88 00:55:06 GMT From: cyrus@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@hc.dspo.gov ------------------------------ Date: Mon, 9 May 88 21:57:03 EDT From: jsol@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 ***********************