Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
On Sun, Oct 18, 1998 at 06:02:15AM -0400, Gregory S. Stark wrote: Branden Robinson [EMAIL PROTECTED] writes: On Fri, Oct 16, 1998 at 10:25:57AM -0700, Ben Gertzfield wrote: Branden Robinson [EMAIL PROTECTED] writes: W: xext: shlib-without-dependency-information usr/X11R6/lib/modules/xf86Jstk.so=20 I have always gotten this error. I don't know how to fix it, but it doesn't seem to hurt anyone. Well, this isn't a shared library that's going to be linked to, so there should be a way to override lintian's behavior. Oh, I get it. The complaint's not about the file itself, but the absence of mention in a shlibs file. Okay. Well, yeah, that should be overridden. The only thing that uses those modules is the X server. Maybe lintian should be modified to only run the shared library checks on files in the standard directories listed in /etc/ld.so.conf ? Actually, James Troup tells me this means that the .so files in question need to be compiled with the -lc option. If Those in the Know could come to a consensus on this, perhaps the lintian error tag and/or info could be rewritten to better explain this error. -- G. Branden Robinson |A committee is a life form with six or Debian GNU/Linux |more legs and no brain. [EMAIL PROTECTED] |-- Robert Heinlein cartoon.ecn.purdue.edu/~branden/ | pgpFOwyrjSltO.pgp Description: PGP signature
Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
At 14:02 -0400 1998-10-16, Branden Robinson wrote: Topi Miettinen has done some research on this. When we get SysV-style pty support in glibc, xterm can lose its root privileges altogether. I hear this will be in glibc 2.1? Yes, that's correct. -- Joel Klecker (aka Espy) URL:mailto:[EMAIL PROTECTED]URL:http://web.espy.org/ Debian GNU/Linux user/developer on i386 and powerpc. URL:mailto:[EMAIL PROTECTED] URL:http://www.debian.org/
Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
On Fri, Oct 16, 1998 at 02:02:21PM -0400, Branden Robinson wrote: On Fri, Oct 16, 1998 at 10:25:57AM -0700, Ben Gertzfield wrote: Branden Robinson [EMAIL PROTECTED] writes: W: xext: shlib-without-dependency-information usr/X11R6/lib/modules/xf86Jstk.so I have always gotten this error. I don't know how to fix it, but it doesn't seem to hurt anyone. Well, this isn't a shared library that's going to be linked to, so there should be a way to override lintian's behavior. Oh, I get it. The complaint's not about the file itself, but the absence of mention in a shlibs file. Okay. Well, yeah, that should be overridden. The only thing that uses those modules is the X server. If you ask me, lintian should ignore files like this outside standard library directories (/lib, /usr/lib, /usr/X11R6/lib). They are almost always modules, eg netscape plugins, etc. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
Branden Robinson [EMAIL PROTECTED] writes: W: xext: shlib-without-dependency-information usr/X11R6/lib/modules/xf86Jstk.so I have always gotten this error. I don't know how to fix it, but it doesn't seem to hurt anyone. Well, this isn't a shared library that's going to be linked to, so there should be a way to override lintian's behavior. E: xfs: postrm-contains-additional-updaterc.d-calls /etc/init.d/xfs Uh, I only call update-rc.d once. What's the problem? [EMAIL PROTECTED]:~]% echo E: xfs: postrm-contains-additional-updaterc.d-calls /etc/init.d/xfs | lintian-info E: xfs: postrm-contains-additional-updaterc.d-calls /etc/init.d/xfs N: N: The postrm de-registers an /etc/init.d script which has not been N: registered in the postinst script before. N: You never registered it in the first place, I would guess? E: xfs: unregistered-script-in-etc-init.d /etc/init.d/xfs Huh? I'm sort of confused by this one as well. Again: [EMAIL PROTECTED]:~]% echo E: xfs: unregistered-script-in-etc-init.d /etc/init.d/xfs | lintian-info E: xfs: unregistered-script-in-etc-init.d /etc/init.d/xfs N: N: The package installs an /etc/init.d script which is not registered in N: the postinst script. N: You forgot to register it in the postinst. W: xlib6: postrm-calls-ldconfig W: xlib6g: postrm-calls-ldconfig Uh, shouldn't they? No! [EMAIL PROTECTED]:~]% echo W: xlib6: postrm-calls-ldconfig | lintian-info 10:19AM W: xlib6: postrm-calls-ldconfig N: N: The postrm script calls ldconfig, which is very dangerous. N: N: Refer to Packaging Manual, chapter 12 for details. N: Chapter 12 says: Any package installing shared libraries in a directory that's listed in /etc/ld.so.conf or in one of the default library directories of ld.so (currently, these are /usr/lib and /lib) must call ldconfig in its postinst script if and only if the first argument is `configure'. However, it is important not to call ldconfig in the postrm or preinst scripts in the case where the package is being upgraded (see Details of unpack phase of installation or upgrade, section 6.3), as ldconfig will see the temporary names that dpkg uses for the files while it is installing them and will make the shared library links point to them, just before dpkg continues the installation and removes the links! Never call ldconfig in postrm (or preinst), especially if the first argument is 'upgrade'. E: xserver-common: binary-without-manpage X X's manpage is in xbase. Hm.. that's not very useful. Why would you need the manpage without the binary? Of course, since xserver-common depends on xbase, it's a bit moot, but I don't know how useful it is to have just a man-page on the system. W: xserver-common: setuid-binary usr/X11R6/bin/X 4755 root/root This a security wrapper. It needs to be setuid root. [EMAIL PROTECTED]:~]% echo W: xserver-common: setuid-binary usr/X11R6/bin/X 4755 root/root | lintian-info W: xserver-common: setuid-binary usr/X11R6/bin/X 4755 root/root N: N: The file is tagged SETUID. In some cases this is intentional, but in N: other cases this is a bug. If it's intentional, please send a note to N: [EMAIL PROTECTED] so that this error gets included in the N: overrides file of Lintian. (With that, Lintian will ignore this bug in N: the future.) N: You need to send a note to [EMAIL PROTECTED] so that it will be overridden. :) X definitely has to be suid. W: xterm: setuid-binary usr/X11R6/bin/xterm 4711 root/root Urp. Will fix in the next release, but since the execute bit *is* set it should work. You'll just have to be root to stare at the naked binary. Be sure to wear sunglasses with strong UV filters. Well, this too needs to be noted to [EMAIL PROTECTED], but it's policy for all binaries that are executable by group or by other should be readable, too, as making them only executable gives no security: 3.3.8 Permissions and owners Setuid and setgid executables should be mode 4755 or 2755 respectively, and owned by the appropriate user or group. They should not be made unreadable (modes like 4711 or 2711 or even 4111); doing so achieves no extra security, because anyone can find the binary in the freely available Debian package--it is merely inconvenient. For the same reason you should not restrict read or execute permissions on non-set-id executables. So make it 4755 and tell lintian-maint to override xterm. (I hate how xterm has to be suid ;) Ben -- Brought to you by the letters Y and P and the number 1. Nerd. Loser. Jerk. Moron. Worm. Scum. Idiot. Fool. -- Pkunk, SCII Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
On Fri, Oct 16, 1998 at 10:25:57AM -0700, Ben Gertzfield wrote: Branden Robinson [EMAIL PROTECTED] writes: W: xext: shlib-without-dependency-information usr/X11R6/lib/modules/xf86Jstk.so I have always gotten this error. I don't know how to fix it, but it doesn't seem to hurt anyone. Well, this isn't a shared library that's going to be linked to, so there should be a way to override lintian's behavior. Oh, I get it. The complaint's not about the file itself, but the absence of mention in a shlibs file. Okay. Well, yeah, that should be overridden. The only thing that uses those modules is the X server. E: xfs: postrm-contains-additional-updaterc.d-calls /etc/init.d/xfs Uh, I only call update-rc.d once. What's the problem? [EMAIL PROTECTED]:~]% echo E: xfs: postrm-contains-additional-updaterc.d-calls /etc/init.d/xfs | lintian-info E: xfs: postrm-contains-additional-updaterc.d-calls /etc/init.d/xfs N: N: The postrm de-registers an /etc/init.d script which has not been N: registered in the postinst script before. N: You never registered it in the first place, I would guess? Uh, I'll check that. E: xfs: unregistered-script-in-etc-init.d /etc/init.d/xfs Huh? I'm sort of confused by this one as well. Again: [EMAIL PROTECTED]:~]% echo E: xfs: unregistered-script-in-etc-init.d /etc/init.d/xfs | lintian-info E: xfs: unregistered-script-in-etc-init.d /etc/init.d/xfs N: N: The package installs an /etc/init.d script which is not registered in N: the postinst script. N: You forgot to register it in the postinst. How do register the init.d script? I thought you just ship it and mark it as a conffile. W: xlib6: postrm-calls-ldconfig W: xlib6g: postrm-calls-ldconfig Uh, shouldn't they? No! You know, I read that part of the policy manual while working on those. Oops. This will definitely hose up people's systems badly. I expect to do another release within the next 24 hours. Sorry about the bandwidth, folks. E: xserver-common: binary-without-manpage X X's manpage is in xbase. Hm.. that's not very useful. Why would you need the manpage without the binary? Of course, since xserver-common depends on xbase, it's a bit moot, but I don't know how useful it is to have just a man-page on the system. Have you read X's manpage? It has nothing to do with our wrapper. This should be overridden. W: xserver-common: setuid-binary usr/X11R6/bin/X 4755 root/root This a security wrapper. It needs to be setuid root. You need to send a note to [EMAIL PROTECTED] so that it will be overridden. :) X definitely has to be suid. Done. (See the To: line of this message). W: xterm: setuid-binary usr/X11R6/bin/xterm 4711 root/root Urp. Will fix in the next release, but since the execute bit *is* set it should work. You'll just have to be root to stare at the naked binary. Be sure to wear sunglasses with strong UV filters. Well, this too needs to be noted to [EMAIL PROTECTED], but it's policy for all binaries that are executable by group or by other should be readable, too, as making them only executable gives no security: Yes, I know. I assume this mode was set my the X makefiles somewhere -- I sure as heck didn't do it. So make it 4755 and tell lintian-maint to override xterm. (I hate how xterm has to be suid ;) Done. Topi Miettinen has done some research on this. When we get SysV-style pty support in glibc, xterm can lose its root privileges altogether. I hear this will be in glibc 2.1? -- G. Branden Robinson | Human beings rarely imagine a god that Debian GNU/Linux| behaves any better than a spoiled child. [EMAIL PROTECTED]| -- Robert Heinlein http://www.ecn.purdue.edu/~branden/ | pgpksWoOotjgO.pgp Description: PGP signature
Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
Again: [EMAIL PROTECTED]:~]% echo E: xfs: unregistered-script-in-etc-init.d /etc/init.d/xfs | lintian-info E: xfs: unregistered-script-in-etc-init.d /etc/init.d/xfs N: N: The package installs an /etc/init.d script which is not registered in N: the postinst script. N: You forgot to register it in the postinst. How do register the init.d script? I thought you just ship it and mark it as a conffile. update-rc.d? Glad to see the big X rewrite is happening, Marcelo
Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Topi Miettinen has done some research on this. When we Branden get SysV-style pty support in glibc, xterm can lose its Branden root privileges altogether. I hear th= is will be in Branden glibc 2.1? SysV-style pty support is a kernel option in linux kernel 2.1.xx (where xx is pretty recent :) so I know the kernel supports it. I don't know how glibc deals with them. -- Brought to you by the letters T and P and the number 19. Oh, all right, Uncle Ulty REALLY wants you to do his portrait. -- FF6 Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
