From felix.schulte at gmail.com Fri Jun 10 19:10:23 2005 From: felix.schulte at gmail.com (Felix Schulte) Date: Fri Jun 10 12:19:58 2005 Subject: [Xprint] Re: SCO port update - what now? In-Reply-To: <42A9B813.80704@sun.com> References: <42A93AF1.9090101@armory.com> <42A9B813.80704@sun.com> Message-ID: <74f15d5f05061009104d0b7294@mail.gmail.com> On 6/10/05, Alan Coopersmith wrote: > Kean Johnston wrote: > > Hi all, > > > > I've posted the patch for teh SCO port update in an attachment to > > #3180. I have a branch, called sco_port_update, that has it all > > committed. What now? How do I get this stuff on the trunk? I am > > working on a full ChangeLog entry if thats all thats missing. > > Looking through the patch, it seems to be pretty reasonable, mostly > SCO-specific, and nothing jumps out at me from the rest. (I'm not > sure the changes to whether monitor refresh rates are commented out > or not in the generated config file should be #ifdef SCO but rather > some more general #ifdef, but that can be cleaned up later.) I don't > see a reason why you shouldn't merge it to head once you have the > changelog done if you think it's ready to go. The changes to the Xprint server seems to be wrong - replacing pread() with lseek()+read() introduces a race condition between parent and child process which both use the same kernel file pointer to read and write to the file (http://lists.freedesktop.org/pipermail/xorg/2005-May/007698.html). -- _ Felix Schulte _|_|_ mailto:felix.schulte@gmail.com (0 0) ooO--(_)--Ooo From felix.schulte at gmail.com Fri Jun 10 19:22:34 2005 From: felix.schulte at gmail.com (Felix Schulte) Date: Fri Jun 10 12:32:08 2005 Subject: [Xprint] Limiting Xprint server access to restricted user group? In-Reply-To: <20050530234143.3953.qmail@web90108.mail.scd.yahoo.com> References: <20050530234143.3953.qmail@web90108.mail.scd.yahoo.com> Message-ID: <74f15d5f050610092271b42c33@mail.gmail.com> On 5/31/05, Peter Macarthur wrote: > Is there a way to limit the access to a Xprint server > to a restricted user group instead of all users on a > machine? We'd like to tighten security on our machines > a little bit and are therefore looking for a way to > increase access control beyond the '-nolisten tcp' > option. > All X.org servers after X11R6.8.0 support a way for authentication of local users and groups. You can exit /etc/init.d/xprint and remove the -ac switch from the list of Xprt start options and then add a "(sleep 30 ; DISPLAY=theprintdisplay:theid xhost +si:localuser:root)". The following section "SERVER INTERPRETED ACCESS TYPES" from http://www.die.net/doc/linux/man/man7/xsecurity.7.html has more information (but lacks examples): -snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip- SERVER INTERPRETED ACCESS TYPES The sample implementation includes several Server Interpreted mechanisms: IPv6 IPv6 literal addresses hostname Network host name localuser Local connection user id localgroup Local connection group id IPv6 A literal IPv6 address as defined in IETF RFC 3513. hostname The value must be a hostname as defined in IETF RFC 2396. Due to Mobile IP and dynamic DNS, the name service is consulted at connection authentication time, unlike the traditional host access control list which only contains numeric addresses and does not automatically update when a host's address changes. Note that this definition of hostname does not allow use of literal IP addresses. localuser & localgroup On systems which can determine in a secure fashion the credentials of a client process, the "localuser" and "localgroup" authentication methods provide access based on those credentials. The format of the values provided is platform specific. For POSIX & UNIX platforms, if the value starts with the character '#', the rest of the string is treated as a decimal uid or gid, otherwise the string is defined as a user name or group name. If your system supports this method and you use it, be warned that some programs that proxy connections and are setuid or setgid may get authenticated as the uid or gid of the proxy process. For instance, some versions of ssh will be authenticated as the user root, no matter what user is running the ssh client, so on systems with such software, adding access for localuser:root may allow wider access than intended to the X display. -snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip- -- _ Felix Schulte _|_|_ mailto:felix.schulte@gmail.com (0 0) ooO--(_)--Ooo From kean at armory.com Fri Jun 10 12:22:18 2005 From: kean at armory.com (Kean Johnston) Date: Fri Jun 10 14:56:02 2005 Subject: [Xprint] Re: SCO port update - what now? In-Reply-To: <74f15d5f05061009104d0b7294@mail.gmail.com> References: <42A93AF1.9090101@armory.com> <42A9B813.80704@sun.com> <74f15d5f05061009104d0b7294@mail.gmail.com> Message-ID: <42A9DA5A.3090901@armory.com> > The changes to the Xprint server seems to be wrong - replacing pread() > with lseek()+read() introduces a race condition between parent and Right, but we have no choice on OSR5, becuase the kernel lacks pread :( Kean From dparsons at debian.org Sat Jun 11 12:05:18 2005 From: dparsons at debian.org (Drew Parsons) Date: Fri Jun 10 21:14:38 2005 Subject: [Xprint] Re: SCO port update - what now? In-Reply-To: <42A9DA5A.3090901@armory.com> References: <42A93AF1.9090101@armory.com> <42A9B813.80704@sun.com> <74f15d5f05061009104d0b7294@mail.gmail.com> <42A9DA5A.3090901@armory.com> Message-ID: <1118451918.19747.0.camel@pug.anu.edu.au> On Fri, 2005-06-10 at 11:22 -0700, Kean Johnston wrote: > > The changes to the Xprint server seems to be wrong - replacing pread() > > with lseek()+read() introduces a race condition between parent and > Right, but we have no choice on OSR5, becuase the kernel lacks pread :( > Couldn't they just copy it from GNU/Linux ? .... Drew From dhighley at highley-recommended.com Wed Jun 22 21:25:36 2005 From: dhighley at highley-recommended.com (David Highley) Date: Wed Jun 22 23:35:16 2005 Subject: [Xprint] Still need a build of xprint Message-ID: <200506230325.j5N3PauH015732@hemlock.highley-recommended.com> Is the xprint project still alive? I need a build to run on a 64 bit Opteron running Fedora core 4 which no longer has Xfree86 libraries. I would build but it comes with an Imake build process which is never ready to use. From dparsons at debian.org Fri Jun 24 15:34:59 2005 From: dparsons at debian.org (Drew Parsons) Date: Fri Jun 24 00:44:51 2005 Subject: [Xprint] dealing with open background processes from /etc/init.d/xprint In-Reply-To: <200506230325.j5N3PauH015732@hemlock.highley-recommended.com> References: <200506230325.j5N3PauH015732@hemlock.highley-recommended.com> Message-ID: <1119587699.8395.29.camel@pug.anu.edu.au> Hi, I'd like to review the way Xprt is launched, comparing Debian GNU/Linux to other Linuces as well as other Unices. On Debian we notice there are a handful of rogue processes appearing when /etc/init.d/xprint is used to start Xprt. "ps aux | grep -i [x]pr" reports something like root 13988 0.0 0.3 4852 1592 pts/4 S 14:15 0:00 /bin/bash /etc/init.d/xprint start root 13989 0.0 0.3 4852 1592 pts/4 S 14:15 0:00 /bin/bash /etc/init.d/xprint start root 13990 1.3 0.9 13332 4740 pts/4 S 14:15 0:00 /usr/X11R6/bin/Xprt -ac -pn -nolisten tcp -audit 4 -fp /usr/lib/X11/fonts/Type1,/usr/local/share/fonts/Mathematica/Type1,/usr/local/Wolfram/MathReader/5.0/SystemFiles/Fonts/Type1,/usr/X11R6/lib/X11/fonts/Type1,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/100dpi/,/usr/lib/X11/fonts/75dpi,/usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/cyrillic,/usr/lib/X11/fonts/misc,/usr/local/share/fonts/Mathematica/BDF,/usr/local/share/fonts/Mathematica/PCF,/usr/local/Wolfram/MathReader/5.0/SystemFiles/Fonts/BDF,/usr/X11R6/lib/X11/fonts/100dpi,/usr/X11R6/lib/X11/fonts/75dpi,/usr/X11R6/lib/X11/fonts/cyrillic,/usr/X11R6/lib/X11/fonts/misc :64 root 13992 0.0 0.3 4852 1596 pts/4 S 14:15 0:00 /bin/bash /etc/init.d/xprint start That is, there are three open processes referring to /etc/init.d/xprint, along side the Xprt process itself. We would expect only the Xprt process to be there, I think. The invoking init script should have finished its job and exited, leaving Xprt running in the background. Would it be possible to ask those of you who do not use Debian to confirm or deny that your system has the same problem with the "rogue" processes? If you don't have them, are you starting Xprt using /etc/init.d/xprint, or some other way? As far as I can tell the processes are remaining due to complicated inner shell processes used to launch Xprt. In the start_servers() function of /etc/init.d/xprint, around ll.618-645 we have something like (shortening down) ( ( # launch Xprt ${Xprt_binary} & # set up /var/run/Xprint_servers ... wait # Xprt failed, so remove reference in /var/run/Xprint_servers ... ) 2>&1 | while read i ; do echo "$i" | tee -a "${xpstart_logfile[$curr]}" | ${xpstart_logger[$curr]} ; done ) <&- >&- 2>&- & One of the rogue processes is due to the wait command, which (if I understood it correctly) waits to see if Xprt failed to start up properly. I haven't been able to evaluate exactly what is holding up the other two processes, however. I have a fix, which uses the utility start-stop-daemon to start Xprt, rather than launching it directly with "${Xprt_binary} &". Debian generally expects us to use this utility in the init scripts, it's designed for just this kind of problem. However start-stop-daemon is (as far as I know) Debian-only, it comes with dpkg, the Debian packaging manager. So I'd be interested to hear if other systems have the same problem, if not then why not. I'd like to evaluate whether to go ahead with my fix for Debian alone, or whether we should build a common solution. A corollary might be to ask if start-stop-daemon is generally useful to other systems :) Thanks, Drew From dparsons at debian.org Fri Jun 24 16:41:22 2005 From: dparsons at debian.org (Drew Parsons) Date: Fri Jun 24 01:51:10 2005 Subject: [Xprint] Still need a build of xprint In-Reply-To: <200506230325.j5N3PauH015732@hemlock.highley-recommended.com> References: <200506230325.j5N3PauH015732@hemlock.highley-recommended.com> Message-ID: <1119591682.8395.33.camel@pug.anu.edu.au> On Wed, 2005-06-22 at 20:25 -0700, David Highley wrote: > Is the xprint project still alive? I need a build to run on a 64 bit > Opteron running Fedora core 4 which no longer has Xfree86 libraries. > Debian compiles for amd64. See http://www.debian.org/ports/amd64/ You could try converting the deb package to rpm using alien. It's at http://amd64.debian.net/debian/pool/main/x/xprint/ > I would build but it comes with an Imake build process which is never > ready to use. imake is built as the first step in Xprint's "make world", isn't it? I suppose you could try recompiling from the Debian source, though I guess that'd give no advantage over compiling from xprint.mozdev.org source. Drew From jstumpel at planet.nl Fri Jun 24 09:07:04 2005 From: jstumpel at planet.nl (Jan Willem Stumpel) Date: Fri Jun 24 02:17:22 2005 Subject: [Xprint] dealing with open background processes from /etc/init.d/xprint In-Reply-To: <1119587699.8395.29.camel@pug.anu.edu.au> References: <200506230325.j5N3PauH015732@hemlock.highley-recommended.com> <1119587699.8395.29.camel@pug.anu.edu.au> Message-ID: <42BBA308.6070600@my.home> Drew Parsons wrote: > Hi, > > I'd like to review the way Xprt is launched, comparing Debian > GNU/Linux to other Linuces as well as other Unices. > > On Debian we notice there are a handful of rogue processes > appearing when /etc/init.d/xprint is used to start Xprt. > > "ps aux | grep -i [x]pr" reports something like > > > root 13988 0.0 0.3 4852 1592 pts/4 S 14:15 0:00 > /bin/bash /etc/init.d/xprint start [..] FYI: I also have Debian (Sid) and three extra processes, but slightly different: /bin/bash /etc/rc2.d/S20xprint start Regards, Jan From dparsons at debian.org Fri Jun 24 17:35:58 2005 From: dparsons at debian.org (Drew Parsons) Date: Fri Jun 24 02:45:45 2005 Subject: [Xprint] dealing with open background processes from /etc/init.d/xprint In-Reply-To: <42BBA308.6070600@my.home> References: <200506230325.j5N3PauH015732@hemlock.highley-recommended.com> <1119587699.8395.29.camel@pug.anu.edu.au> <42BBA308.6070600@my.home> Message-ID: <1119594958.8395.45.camel@pug.anu.edu.au> On Fri, 2005-06-24 at 08:07 +0200, Jan Willem Stumpel wrote: > Drew Parsons wrote: > > > > On Debian we notice there are a handful of rogue processes > > appearing when /etc/init.d/xprint is used to start Xprt. > > > > "ps aux | grep -i [x]pr" reports something like > > > > > > root 13988 0.0 0.3 4852 1592 pts/4 S 14:15 0:00 > > /bin/bash /etc/init.d/xprint start [..] > > FYI: I also have Debian (Sid) and three extra processes, but > slightly different: /bin/bash /etc/rc2.d/S20xprint start > Aye I know, that's what I'm trying to fix :) By the way, the font printing problem you reported disappeared between March and May. I was all set to celebrate. But it's back again this month :( Another user suspects it's happening due to faulty font hints, preventing the X[print] server accessing the appropriate fonts. He's looking into it further at the moment (bug #251067). Drew