On Fri, Oct 16, 1998 at 10:25:57AM -0700, Ben Gertzfield wrote: > Branden Robinson <branden.robinson@ibm.net> 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? > > [ben@gilgamesh:~]% 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: > > [ben@gilgamesh:~]% 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 lintian-maint@debian.org 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 lintian-maint@debian.org, 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. branden.robinson@ibm.net | -- Robert Heinlein http://www.ecn.purdue.edu/~branden/ |
Attachment:
pgpk0TQL4Qea3.pgp
Description: PGP signature