Thread: [XonX-Users] Xterm SUID?
Brought to you by:
torrey
From: John D. P. <joh...@ma...> - 2004-12-23 03:08:53
Attachments:
smime.p7s
|
Hi! I've got a few questions: 1) Why is Xterm SUID? 2) Shouldn't that be explicitly disabled on Darwin? 3) Shouldn't the default be not-SUID, and systems that require it explicitly set it to be SUID? Thanx, JP -- When life hands you lemons, ask for a bottle of gin and tonic. |
From: Torrey L. <to...@mr...> - 2004-12-23 17:00:17
|
At 7:08 PM -0800 12/22/04, John Davidorff Pell wrote: >Hi! > >I've got a few questions: >1) Why is Xterm SUID? The short answer is so that it can chown the pseudo tty that it uses. The long answer is that it does not absolutely need to do this and in any case there are non-SUID ways to do this. Apple's X11 does not have an SUID xterm and it just fails to chown the tty. The main symptom of this is that if you use "who" you will not see your xterm sessions listed. On the other hand if you open up a bunch of SUID xterm or Terminal.app windows you will see them all listed in who. Terminal.app is not SUID so there is clearly another way to do this. Most OS'es have provided some non-SUID way to do this, but this is not standard. If we knew how to do this on Mac OS X we could have xterm do this instead. >2) Shouldn't that be explicitly disabled on Darwin? Perhaps. We left it that way since it had always been that way and it does modify behavior if you change it. You can change this yourself by putting the following line in your xc/config/cf/host.def file before you build: #define InstallXtermSetUID YES >3) Shouldn't the default be not-SUID, and systems that require it >explicitly set it to be SUID? Perhaps, but since the Xserver is also SUID on many platforms it sticks out less than as the only SUID X11 program on Mac OS X. --Torrey |
From: John D. P. <joh...@ma...> - 2004-12-24 08:59:27
Attachments:
smime.p7s
|
On 23 Dec 2004, at 08:59, Torrey Lyons wrote: > At 7:08 PM -0800 12/22/04, John Davidorff Pell wrote: > > >> Hi! >> >> I've got a few questions: >> 1) Why is Xterm SUID? >> >> > > The short answer is so that it can chown the pseudo tty that it uses. > The long answer is that it does not absolutely need to do this and in > any case there are non-SUID ways to do this. Apple's X11 does not have > an SUID xterm and it just fails to chown the tty. The main symptom of > this is that if you use "who" you will not see your xterm sessions > listed. On the other hand if you open up a bunch of SUID xterm or > Terminal.app windows you will see them all listed in who. Terminal.app > is not SUID so there is clearly another way to do this. Most OS'es > have provided some non-SUID way to do this, but this is not standard. > If we knew how to do this on Mac OS X we could have xterm do this > instead. Terminal.app launches /usr/bin/login, which is prolly the best thing to do, as it is something that must be SUID anyway, and so should handle all the things together that might require that. This has the unfortunate side-effect of launching the default login shell... oh, wait, that's what its supposed to do. ;-) >> 2) Shouldn't that be explicitly disabled on Darwin? >> >> > Perhaps. We left it that way since it had always been that way and it > does modify behavior if you change it. You can change this yourself by > putting the following line in your xc/config/cf/host.def file before > you build: > > #define InstallXtermSetUID YES Do you mean to set this to NO? Thanx, I wasn't sure how to turn that off. :-) >> 3) Shouldn't the default be not-SUID, and systems that require it >> explicitly set it to be SUID? >> >> >> > > Perhaps, but since the Xserver is also SUID on many platforms it > sticks out less than as the only SUID X11 program on Mac OS X. > > SUID binaries are something that I have a pet-peeve about. I think that they should never be the default and, where required, are usually design-flaws. Thanx, JP ---- It's all fun and games 'til someone writes to a NULL pointer! |
From: Patrik M. <pa...@ch...> - 2004-12-30 21:27:25
|
On 04-12-24 09.59, John Davidorff Pell (joh...@ma...) wrote: > > On 23 Dec 2004, at 08:59, Torrey Lyons wrote: > > >> At 7:08 PM -0800 12/22/04, John Davidorff Pell wrote: >> >> >>> Hi! >>> >>> I've got a few questions: >>> 1) Why is Xterm SUID? >> >> The short answer is so that it can chown the pseudo tty that it uses. >> The long answer is that it does not absolutely need to do this and in >> any case there are non-SUID ways to do this. Apple's X11 does not have >> an SUID xterm and it just fails to chown the tty. The main symptom of >> this is that if you use "who" you will not see your xterm sessions >> listed. On the other hand if you open up a bunch of SUID xterm or >> Terminal.app windows you will see them all listed in who. Terminal.app >> is not SUID so there is clearly another way to do this. Most OS'es >> have provided some non-SUID way to do this, but this is not standard. >> If we knew how to do this on Mac OS X we could have xterm do this >> instead. Chowning the tty is not what makes terms show up to who. Who only reads out the current users from /etc/utmp - which is 644 root, so xterm needs to be root to write in it. Terminal doesn't write in utmp, so multiple Terminal windows don't show up several times. Loginwindow (I think) writes in utmp when you log in, so a graphical session shows up on who even if there are no Terminal windows open. The same way sshd writes in utmp if you log in that way. The logical thing would be to have XDM write in utmp - it's obviously running as root anyway. Just launching X11 should not write in utmp - you're not logging in again, you're just launching another process. I don't know why xterm chowns the tty. There is probably a good historical reason for it, but you can work without owning the tty today. > Terminal.app launches /usr/bin/login, which is prolly the best thing to > do, as it is something that must be SUID anyway, and so should handle > all the things together that might require that. This has the > unfortunate side-effect of launching the default login shell... oh, > wait, that's what its supposed to do. ;-) Are you sure that's what it does? I don't think Terminal.app does anything that requires root access. I think it only launches the relevant shell as a login shell - you don't get a login prompt when you open a Terminal window, do you? If you check the archives for this list (should be at sourceforge, right?), you will find an old discussion between Torrey, Greg Parker and yours truly. The subject has been up before. >>> 3) Shouldn't the default be not-SUID, and systems that require it >>> explicitly set it to be SUID? >> Perhaps, but since the Xserver is also SUID on many platforms it >> sticks out less than as the only SUID X11 program on Mac OS X. > SUID binaries are something that I have a pet-peeve about. I think that > they should never be the default and, where required, are usually > design-flaws. What, you mean that xterm is not the perfect terminal? I'm shocked! Really, xterm is very old. The source is hard to work with. Its one redeeming feature is that it supports every terminal protocol since cuniform, but that's a pretty big feature. Of course having a big userland app like xterm suid is a big security risk, and I think everyone understands that. Note that rxvt is not suid root. If it were up to me, I'd make rxvt (or some other modern terminal app) the new default xterm, modify XDM to write in the user log (seems like the logical way to me - if you log in graphically to an X11 terminal and use only shortcuts in the window manager to launch programs, you don't write anything in utmp or even in wtmp, the user log) and keep the old xterm as an optional install for those situations where you need odd terminal protocols. Alternatively, just determine the platforms where chowning the tty is necessary and making it suid on those platforms only. Oh, and change the default so it doesn't write into utmp - it can be done with a switch at launch today. -- Patrik Montgomery // pa...@ch... |
From: John D. P. <joh...@ma...> - 2004-12-31 00:19:26
Attachments:
smime.p7s
Picture 1.png
|
On 30 Dec 2004, at 13:27, Patrik Montgomery wrote: >> Terminal.app launches /usr/bin/login, which is prolly the best thing >> to >> do, as it is something that must be SUID anyway, and so should handle >> all the things together that might require that. This has the >> unfortunate side-effect of launching the default login shell... oh, >> wait, that's what its supposed to do. ;-) >> > Are you sure that's what it does? I don't think Terminal.app does > anything > that requires root access. I think it only launches the relevant shell > as a > login shell - you don't get a login prompt when you open a Terminal > window, > do you? If you check the archives for this list (should be at > sourceforge, right?), > you will find an old discussion between Torrey, Greg Parker and yours > truly. > The subject has been up before. Yes, I'm sure that's what it does. I use pstree to show how its laid out. Attached is a pretty screen-shot from Activity Monitor. It does not, however, do this if in Preferences you have it launch a specific shell (even if that shell is your login shell). It does not just launch login, the command line used is "login -pf userName" -p makes it preserve the environment and -f makes it accept the user name, with no password, so long as it is being run by either root or that user. It does make your shell show up in who(1) or w(1). I'm not sure if those flags are portable, but if they are generally accepted or equivalents are available then that should be the norm, always, on every platform. This means that Xterm never has to query for the login shell, and it means that there are not ugly races in modifying utmp or whatever. It would even work on systems where that file does not exist and users are tracked by some other method. JP |