wsherman@newton.ncsa.uiuc.edu (William Sherman -Visualization) (09/27/90)
I'll ask the question before I lose my audience. With the new method for starting up X manually, I'm having trouble getting an X application begin automatically upon loging in. My ~/.xSGINeWS.cmd file contains the command "/usr/bin/X11/Xsgi -bs -pseudo", and I do an "xstart -c" before starting the application. I tried putting a sleep command between the two, but that didn't help. Any suggestions? Okay, my first complaint is about something I'm sure SGI considers a "feature." I have some shell scripts to mount and unmount nfs'ed disks to allow me to adapt to network problems, and machines going down. Of course only the superuser can do this, so the scripts are owned by root, and the setuid bit is set. Well, under 3.3.1, I'm informed that "mount_x: Setuid shell scripts not allowed." Is there anything I can do to allow them? If not, there should be. I'm curious as to the reason the arrow keys on the numeric pad now return the same key-codes as the four arrow keys grouped between the keypad and the main section. It seems that if people wanted them to give the same codes, they could do key remapping in their user.ps. How soon before we have to wait for a fix for mail? I understand from a friend, a problem with file-locking causes IRIX to think the mailboxes are corrupted after the filesize is brought down to zero. Is this a serious enought problem to bring about 3.3.2? I prefer to run mail on the same machine I do most of my work on, rather than rlogining onto some foreign system. /************************************************************************/ /* Bill Sherman */ /* National Center for Supercomputing Applications */ /* University of Illinois */ /* Champaign-Urbana */ /* */ /* Internet: wsherman@ncsa.uiuc.edu */ /* */ /* "You want to do mankind a real service? Tell funnier jokes." */ /* Og */ /************************************************************************/
jweldon@sgi.com (Jack P. Weldon) (09/28/90)
In article <1990Sep26.174852.1344@ux1.cso.uiuc.edu> wsherman@newton.ncsa.uiuc.edu (William Sherman -Visualization) writes: >I'll ask the question before I lose my audience. With the new method > [X startup question deleted--sorry] >Okay, my first complaint is about something I'm sure SGI considers >a "feature." I have some shell scripts to mount and unmount nfs'ed >disks to allow me to adapt to network problems, and machines going >down. Of course only the superuser can do this, so the scripts are >owned by root, and the setuid bit is set. Well, under 3.3.1, I'm >informed that "mount_x: Setuid shell scripts not allowed." Is there >anything I can do to allow them? If not, there should be. > In 3.3, there is a flag to allow suid shell scripts which is shipped "off" for security reasons. Edit /usr/sysgen/master.d/kernel and change the line "int nosuidshells = 1;" to 0. Then run /etc/init.d/autoconfig and reboot (or use lboot if you wish--both build a kernel). Needless to say you must be root to do this...And YES, it *is* a feature, not a bug. -- Cheers, Jack P. Weldon (jweldon@csd.sgi.com)
bernie@umbc3.UMBC.EDU (Bernard J. Duffy) (09/28/90)
In article <1990Sep26.174852.1344@ux1.cso.uiuc.edu> wsherman@newton.ncsa.uiuc.edu (William Sherman -Visualization) writes: ... (X stuffs deleted) > >Okay, my first complaint is about something I'm sure SGI considers >a "feature." I have some shell scripts to mount and unmount nfs'ed >disks to allow me to adapt to network problems, and machines going >down. Of course only the superuser can do this, so the scripts are >owned by root, and the setuid bit is set. Well, under 3.3.1, I'm >informed that "mount_x: Setuid shell scripts not allowed." Is there >anything I can do to allow them? If not, there should be. > ... other stuffs deleted... > >/* Bill Sherman National Center for Supercomputing Applications */ >/* University of Illinois Champaign-Urbana */ Bill, I've been told that suid scripts are dangerous, so I put my {,u}mount command for an optical drive (have to change platters from time to time). The program is real simple and I've over-commented it below. I needed to use getgid() to restrict use to the group of users that owned the optical drive. Other command(s) could be enveloped in this manner. Here's the program : /* cut here ...... */ /* moptical.c - Allow someone of the groupS group to become root and execute the /etc/mount /chem2/optical (or /etc/umount /chem2/optical if executed with uoptical softlink) command without the hassle of typing in the root passwd (or even knowing it). Author: Bernie Duffy, Academic Computing Date: Jan. 19, 1990 To install it: (Executible must, of course, be suid.) ! on chem3 cd /usr/local/grps/src/moptical newgrp groupS cc moptical.c -o /usr/local/grps/bin/moptical cd /usr/local/grps/bin ln -s /usr/local/grps/bin/moptical uoptical chmod 4750 moptical # ls -l /usr/local/grps/bin/*opt* -rwsr-x--- 1 root groupS 42664 Jan 19 17:50 moptical* l--------- 1 root groupS 28 Jan 19 17:51 uoptical@ -> /usr/local/grps/bin/moptical */ #include <stdio.h> #define GROUPID 30 #define GROUPNAME "groupS" #define DISKPARTITION "/chem2/optical" main (argc,argv) int argc; char **argv; { if (getgid() != GROUPID && getuid() != 0) { fprintf(stderr, "You don't belong to the %s group, sorry.\n", GROUPNAME); exit(0); } printf ("Please wait... "); setuid(0); if ( strncmp (argv[0], "moptical", 8) == 0 ) { printf("Mounting %s : mount -c %s\n", DISKPARTITION, DISKPARTITION); execlp("/etc/mount", "mount", "-c", DISKPARTITION, (char *) 0); } else { printf("Un-mounting %s : umount %s\n", DISKPARTITION, DISKPARTITION); execlp("/etc/umount", "umount", DISKPARTITION, (char *) 0); } perror(argv[0]); exit(0); } /* end of moptical.c program. execlp() will only return if there is a permission or process creation error... that's the only way exit(0); will get called. */ -- Bernie Duffy Systems Programmer II | Bitnet : BERNIE@UMBC2 Academic Computing Services - L005e | Internet : BERNIE@UMBC2.UMBC.EDU Univ. of Maryland Baltimore County | UUCP : ...!uunet!umbc3!bernie Baltimore, MD 21228 (U.S.A.) | W: (301) 455-3231 H: (301) 744-2954
dana@tread.sgi.com (Dana Treadwell) (09/28/90)
>From: wsherman@newton.ncsa.uiuc.edu (William Sherman -Visualization) >> ...Well, under 3.3.1, I'm >> informed that "mount_x: Setuid shell scripts not allowed." Is there >> anything I can do to allow them? If not, there should be. Yes, see /usr/sysgen/master.d/kernel: /* * to allow setuid shells set to 0 */ int nosuidshells = 1; Make the change, run /etc/init.d/autoconfig to reconfigure your kernel and reboot. Dana dana@sgi.com
jdh@bu-pub.bu.edu (Jason Heirtzler) (09/28/90)
It looks like the "nosuid" mount option isn't provided as well. This would be a very useful thing, especially when you want to cross mount NFS filesystems from different administrative domains. Any plans to provide this in the near future? ------------------------------------------------------------------- Jason Heirtzler (617) 353-2780 jdh@bu-pub.bu.edu Information Technology Boston University ..!bu.edu!bu-pub!jdh
guy@auspex.auspex.com (Guy Harris) (09/30/90)
>It looks like the "nosuid" mount option isn't provided as well. This >would be a very useful thing, especially when you want to cross mount >NFS filesystems from different administrative domains. > >Any plans to provide this in the near future? If you do, consider either 1) having the "nosuid" option *also* disallow access to character and block special files on a file system mounted "nosuid" (regardless of whether the file system is a local one or an NFS-mounted one) or 2) providing an option to disallow that access.... (We chose 1) here, and I suggested it to Sun as well, complete with suggested code changes....)
mitch@sgi.com (Thomas Mitchell) (10/23/90)
In article <1990Sep27.192121.18059@odin.corp.sgi.com> jweldon@sgi.com (Jack P. Weldon) writes: * In article <1990Sep26.174852.1344@ux1.cso.uiuc.edu> wsherman@newton.ncsa.uiuc.edu (William Sherman -Visualization) writes: * >I'll ask the question before I lose my audience. With the new method * * > [X startup question deleted--sorry] * * >Okay, my first complaint is about something I'm sure SGI considers * >a "feature." I have some shell scripts ^SUID * * In 3.3, there is a flag to allow suid shell scripts which is shipped * "off" for security reasons. Edit /usr/sysgen/master.d/kernel and change * the line "int nosuidshells = 1;" to 0. Then run /etc/init.d/autoconfig * and reboot (or use lboot if you wish--both build a kernel). Needless to * say you must be root to do this...And YES, it *is* a feature, not a bug. Better to write a 'c' program and make it SUID. It can (should) be very simple. Just issue a "system()" call to do exactly what you wish no more no less. Do read the book "UNIX System Security" by Patrick H. Wood and Stephen G. Kochan Hayden Book Company ISBN 0-8104-6267-2 The program can have an access list, keep track of who what when, what is mounted etc. Of course if you are the only user and not on a network turn the bit off in the kernel as above. Shell scripts are much shorter than 'c' programs. Compare: #!/bin/sh echo '\0220'1.y$1'\0234' With the size of a 'c' program to set the title bar of a 'wsh' window. -- -- Thomas P. Mitchell -- mitch@sgi.com or mitch%relay.csd@sgi.com "All things in moderation; including moderation."
mitch@sgi.com (Thomas Mitchell) (10/27/90)
In article <1990Oct22.233456.4861@odin.corp.sgi.com> mitch@sgi.com (Thomas Mitchell) writes: * In article <1990Sep27.192121.18059@odin.corp.sgi.com> jweldon@sgi.com (Jack P. Weldon) writes: * * In article <1990Sep26.174852.1344@ux1.cso.uiuc.edu> wsherman@newton.ncsa.uiuc.edu (William Sherman -Visualization) writes: * * * >..... some shell scripts * ^SUID * * * In 3.3, there is a flag to allow suid shell scripts which is shipped * * "off" for security reasons. I said: better to not use it and, * Better to write a 'c' program and make it SUID. It can * (should) be very simple. Just issue a "system()" call to do * exactly what you wish no more no less. Do read the book * "UNIX System Security" by Patrick H. Wood and Stephen G. Kochan * Hayden Book Company ISBN 0-8104-6267-2 Yes, good book, share a copy with a friend. * Of course if you are the only user and not on a network * turn the bit off in the kernel as above. Shell scripts * are much shorter than 'c' programs. A number of kind people sent me notes regarding this. Some correctly felt I should have pointed users at execv() first and not system(). One of the reasons for not using the system() call "is related to the principle of least astonishment: the less programs invoked, the better. system() allows too many security holes to open because it invokes a shell". KNOWING that a sh'ell is invoked is key here. I elected to use the system() call because the way I intended to use it. It provided me with a much better solution than opening the barn door and turning on the kernel bit. I should note: Most carefully crafted programs use execv(). It is very important to know your neighborhood. Those who live on or very near the internet need assess their needs and act accordingly. Those not on the internet also need to be aware of their environment. Perhaps the best example was a person I worked with who had a timed problem. His system time kept getting reset wrong by 5 hours. Well it turned out his 'network' spanned 5 timezones. The individual did not know it left the building -- let alone the continent. A short, looong distance call to the manager of the other system cleared things up. Thanks, mitch -- -- Thomas P. Mitchell -- mitch@sgi.com or mitch%relay.csd@sgi.com "All things in moderation; including moderation."