peterf@csis.dit.csiro.au (Peter A Fletcher) (04/08/91)
Hi! There's a really frustrating bug with Xterm, and I was wondering
if anyone knew a way around it.
For some reason, xterm is setuid root. I don't know what good this
does, but it can prevent xterms from writing to log-files on NFS
partitions (because NFS prevents root from writing across filesystems).
This normally has no effect, but it can prevent the xterm from
writing log files.
Is there any pressing reason for xterm to be suid root ? Is there
any fix for my problem ?
I'm running with a network of SUN 4's.
-peter.
(peterf@csis.dit.csiro.au; phone +61 6 2750914)
--
Peter Fletcher, PhD student. Internet : peterf@csis.dit.csiro.au
Phone : +61-6-2750914 Physical : CSIRO Division of Information Technology,
ANU, Acton, Canberra ACT AUSTRALIA
-----------------------------------------------------------------------------------------mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (04/10/91)
> There's a really frustrating bug with Xterm, and I was wondering if > anyone knew a way around it. > For some reason, xterm is setuid root. I don't know what good this > does, It's so that xterm can write /etc/utmp and change the owner of the pseudo-tty it allocates. > but it can prevent xterms from writing to log-files on NFS partitions > (because NFS prevents root from writing across filesystems). Or rather, a common (mis)feature in NFS implementations prevents it. There is nothing about NFS per se that has anything to do with UID=0 accesses. > This normally has no effect, but it can prevent the xterm from > writing log files. Under what circumstances? I just did a test, and xterm was capable of creating and writing a logfile under circumstances which prevented root from creating files. (UID 103, directory owned by UID 103 and mode 755, root could not create files there (with touch) but xterm -l did.) > Is there any pressing reason for xterm to be suid root ? Not unless you want utmp entries for your xterm windows. (Unless you make utmp world-writeable, which opens up other, fairly serious, security holes, but that may be acceptable in trusting environments.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/11/91)
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: >> Is there any pressing reason for xterm to be suid root ? >Not unless you want utmp entries for your xterm windows. (Unless you >make utmp world-writeable, which opens up other, fairly serious, >security holes, but that may be acceptable in trusting environments.) An alternate strategy that involves UNIX's "philosophy" of having extra processes: Write a root program called xutmp or something like that. When xterm is going to otherwise exec the shell in its child under conditions it would update utmp, it should instead exec xutmp. What xutmp will do is update the utmp, fork again and exec the shell, and wait for the shell to exit. When the shell exits, update utmp and exit back to xterm. It would be YET ANOTHER PROCESS, but it seems often that UNIX programmers are already rather liberal with processes, so only the critics of such programmers should complain (I'm not sure if I am or not). xutmp would have to be smart enough to deal with cases of whether or not utmp already reflects an entry for the same tty, and NOT any updates if that is the case (and it can bypass the fork in that case as well). That would prevent some user messing up utmp. Then xterm could run as owned by the user (and those of us without root ids can kill all those errant xterms that seem to hang around all the time). -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks / \***************************************************************************/
lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) (04/19/91)
In article <1991Apr10.222541.14268@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: >mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: > >>> Is there any pressing reason for xterm to be suid root ? > >>Not unless you want utmp entries for your xterm windows. (Unless you >>make utmp world-writeable, which opens up other, fairly serious, >>security holes, but that may be acceptable in trusting environments.) > >An alternate strategy that involves UNIX's "philosophy" of having extra >processes: There's an alternate Unix philosophy, that of using group permissions, that just might do the job. /etc/utmp is usually in the system group. So why not make it group writable, and make xterm setgid-system? This seems like the way things really oughta be done, and you do away with yet another spuriously-setuid-root program. I think I'll try it on a few systems, and see what breaks... ...Nope, nothing broke. I started up a bunch of windows to/from this system, did an assortment of rlogins, and so on, verified that the new windows corresponded to entries in /etc/utmp, and everything seems to work fine. When I type ls -ldg /etc/utmp `which xterm` the result is: -rw-rw-r-- 1 root system 1512 Apr 18 16:47 /etc/utmp -rwxr-sr-x 1 root system 387072 Aug 31 1990 /usr/bin/X11/xterm So I'd conclude that, unless I've missed something suble, setuid-root isn't necessary for xterm, and setgid-system suffices, if all the appropriate files are in the system group and are group writable. It might help if we could get a definitive list of just what files xterm wants to write. Now if such a demo only worked so well for sendmail, which really *really* shouldn't be setuid-root but almost always is...
barmar@think.com (Barry Margolin) (04/19/91)
In article <22173@shlump.nac.dec.com> lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: >So I'd conclude that, unless I've missed something suble, setuid-root isn't >necessary for xterm, and setgid-system suffices, if all the appropriate >files are in the system group and are group writable. Doesn't the -C option, which redirects console output to the xterm window, use an ioctl that requires root access? Also, does xterm need to chown() the tty device special file to the user? Or does the tty driver do this automatically when the process opens it? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
schoch@trident.arc.nasa.gov (Steve Schoch) (04/25/91)
In article <22173@shlump.nac.dec.com>, lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: |> In article <1991Apr10.222541.14268@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: |> >mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: |> > |> >>> Is there any pressing reason for xterm to be suid root ? |> > |> >>Not unless you want utmp entries for your xterm windows. (Unless you |> >>make utmp world-writeable, which opens up other, fairly serious, |> >>security holes, but that may be acceptable in trusting environments.) There's another (bigger, in my opinion) security hole created by NOT making xterm setuid root. When it is suid root, it changes the owner and permissions of your pty so that things like mesg, biff, etc work. If it is not suid root, then your pty will remain owned by root, mode 666. This means that anyone can write to, and read from (!) your xterm. This can cause input you type to go to somebody's cracking program rather than the program you are trying to run. Steve
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (05/02/91)
>> So I'd conclude that, unless I've missed something suble, >> setuid-root isn't necessary for xterm, and setgid-system suffices, >> if all the appropriate files are in the system group and are group >> writable. I think you're mostly right, though tty ownerships still won't get set properly. > Doesn't the -C option, which redirects console output to the xterm > window, use an ioctl that requires root access? (I am assuming the systems in question are Suns.) TIOCCONS, it is. No, anyone can use it. This is somewhat dangerous, as it allows anyone to steal the console from whoever (if anyone) is using it - even when there's no bitmap screen. I understand there is a fix that disallows TIOCCONS if the caller can't already read from the console, which seems reasonable. I would also like to have a variable somewhere in the kernel, patchable with adb for example, that would disallow TIOCCONS entirely. > Also, does xterm need to chown() the tty device special file to the > user? Yes, and for this xterm needs setuid-root, though a proper rework of the pty stuff would cure it. > Or does the tty driver do this automatically when the process opens > it? It pretty much can't; ownership is an attribute of the special device file, not of the device itself. The driver has no access to the pathname with which the process opened the file. In the case of pseudo-ttys, it might be workable to assume sprintf(...,"/dev/tty%c%x",'p'+(ptyno/16),ptyno%16) but that seems like a dreadful kludge to me. I would much rather build a proper pty mechanism. (Just what that would be, I'm not sure. I haven't thought about it much.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu