From: Juliusz Chroboczek <[EMAIL PROTECTED]> Subject: Re: Some patches to luit Date: 14 Mar 2003 19:28:42 +0100 > IT> It seems xc/programs/luit/sys.c in XFree86 4.3.0 contains a off-by-one > IT> bug. A patch (sys.c.patch) to fix this is attached. > > This is correct. Thanks, I've forwarded it to the patchers.
I am glad to hear it. > IT> - Make luit use openpty to search an unused pty. Without this patch, > IT> luit aborts after opening ten or so xterms. > > Could you explain why this happens? allocatePty in sys.c searches > through 256 ptys. On the default installation of FreeBSD 4.x, /dev does not have pty[qrs]* device nodes. allocatePty in sys.c searches /dev/pty[p-zP-T][0-9a-f], which results in only 16 nodes on FreeBSD 4.x. | $ cd /dev && ls pty* | ptyp0 ptyp4 ptyp8 ptypc ptypg ptypk ptypo ptyps | ptyp1 ptyp5 ptyp9 ptypd ptyph ptypl ptypp ptypt | ptyp2 ptyp6 ptypa ptype ptypi ptypm ptypq ptypu | ptyp3 ptyp7 ptypb ptypf ptypj ptypn ptypr ptypv Though one can create /dev/ptyq[0-9a-v] by executing | $ cd /dev && ./MAKEDEV pty1 and so on, I'd like to get xterm and luit work without touching the default installation if I can. Things may be different on FreeBSD 5.x, which have DEVFS. I do not know much about them. > I strongly dislike the openpty interface, which I feel is badly > designed. Indeed, your patch causes luit to open the slave side in the > parent, which feel wrong. I do not know much about ptys. I found openpty in manpage and just wrote in the way which seemed to work. I am fine if luit searches /dev/pty[p-zP-T][0-9a-v] instead of /dev/pty[p-zP-T][0-9a-f]. Is this modification acceptable? > Your patch also breaks support for systems with SVR4 ptys. This > cannot go in. I know it, and I am glad if anyone has an idea to get it integrated into the original code without breaking the code for other systems. > IT> - Allow one to setuid luit. > > This one is incorrect; it is a serious security hole, not only on > FreeBSD but on all systems that have saved-ids that don't respect the > Posix semantics. Again, I had only FreeBSD in mind when I wrote the patch. In addition, I forgot to mention I had only setuid-root case and non-setuid case in mind. As long as the luit is setuid'ed to root or not setuid'ed at all, the function drippriv behaves in the same manner on FreeBSD as on the systems with POSIX-compliant set[ug]id, I think. >From what I've learned from a quick search, FreeBSD's and POSIX's setuid are different only when called from processes which are setuid'ed to other user than root. Am I wrong? On FreeBSD, calling setuid sets all of the real, effective and saved user-IDs to the specified user-ID, and setgid is similar to this. I do not know what happens if luit with luit-freebsd.patch is setuid'ed to a non-root user. But I do not think this is a big problem, though the patch may be refined to make luit refuse to run if luit is setuid'ed to a non-root user. > Luit will check for Posix saved IDs, and refuse to run if it's setuid > on systems that have the (broken) 4.3BSD saved-ids semantics. Your > patch merely removes this check. Yes. This will break the safety barrier in luit on other systems than FreeBSD. Again, I want a way to integrate this to make the code work properly on all the systems. Best regards, Tsuyoshi --- ITO Tsuyoshi <[EMAIL PROTECTED]> --- --- Dept. of Computer Science, University of Tokyo. --- _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
