Re: Could someone clarify dpkg-statoverride please? (Was Re: dpkg-statoverride and creating users in postinst)
Package: dpkg Version: 1.8.3.1 Severity: minor On Tue, Feb 13, 2001 at 09:38:35AM +0100, J?r?me Marant wrote: This is an extract from dpkg-statoverride manpage: `stat overrides' are a way to tell dpkg to use a different owner or mode for a file when a package is installed. (note: I use the word `file' here, but in reality this can be any filesystem object that dpkg handles, including directories, devices, etc.). This can be used to force programs that are normall setuid to be install without a setuid flag, or only executable by a certain group. "This can be used *by the sysadmin* to force..." The manpage should be clarified. However, the use of dpkg-statoverride within a package is yet unclear to me. You don't ever use it to set permissions in maintainer scripts; see below. With suidregister, we used to: - override setuid/setgid when building the package (debian/rules) - readd setuid/setgid permissions in the postinst with suidregister - remove setuid/setgid permissions in the postrm with suidunregister Almost. We asked suidregister to set (not necessarily add) the setuid/setgid permissions as required. suidregister would note the package maintainer's request and compare it to its existing database. If there was a manual override present, the maintainer's version would be ignored, otherwise it would be used. Can someone tell me what's exactly to be done now with dpkg-statoverride? Can we embbed setuid/setgid executables in the package and dpkg-statoverride will be used only to override permissions to non-setuid/non-setgid ? In the new setup, we put the most usual version in the .deb; if the program would normally be run setuid/setgid then that is what should be in the .deb; if it is normally run non-setuid/non-setgid, then that should be put in the .deb. Should the sysadmin wish to change things from the default, they run the dpkg-statoverride --update --add command, and then that becomes the default from then on. Dpkg will automatically examine the statoverride file every time a package is installed to see whether there are any local statoverrides; you don't need to do anything in your maintainer scripts any longer. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Could someone clarify dpkg-statoverride please? (Was Re: dpkg-statoverride and creating users in postinst)
Julian Gilbey [EMAIL PROTECTED] writes: No, you shouldn't do it like this. You should do: dpkg-statoverride --list ..., examine the output to see if a specific mode/uid/gid is required, and if not, then just use a chmod. *Don't* use dpkg-statoverride --add, for then there will be no way of knowing whether or not the admin has added the override or the package has. This is an extract from dpkg-statoverride manpage: `stat overrides' are a way to tell dpkg to use a different owner or mode for a file when a package is installed. (note: I use the word `file' here, but in reality this can be any filesystem object that dpkg handles, including directories, devices, etc.). This can be used to force programs that are normall setuid to be install without a setuid flag, or only executable by a certain group. The following Joey Hess's post ... http://lists.debian.org/debian-devel-announce-0101/msg4.html explains how to make the transition between suidregister and dpkg-statovveride. However, the use of dpkg-statoverride within a package is yet unclear to me. With suidregister, we used to: - override setuid/setgid when building the package (debian/rules) - readd setuid/setgid permissions in the postinst with suidregister - remove setuid/setgid permissions in the postrm with suidunregister Can someone tell me what's exactly to be done now with dpkg-statoverride? Can we embbed setuid/setgid executables in the package and dpkg-statoverride will be used only to override permissions to non-setuid/non-setgid ? -- Jérôme Marant [EMAIL PROTECTED] --- Debian Activity Page: http://jerome.marant.free.fr/debian ---
Re: Could someone clarify dpkg-statoverride please? (Was Re: dpkg-statoverride and creating users in postinst)
Package: dpkg Version: 1.8.3.1 Severity: minor On Tue, Feb 13, 2001 at 09:38:35AM +0100, J?r?me Marant wrote: This is an extract from dpkg-statoverride manpage: `stat overrides' are a way to tell dpkg to use a different owner or mode for a file when a package is installed. (note: I use the word `file' here, but in reality this can be any filesystem object that dpkg handles, including directories, devices, etc.). This can be used to force programs that are normall setuid to be install without a setuid flag, or only executable by a certain group. This can be used *by the sysadmin* to force... The manpage should be clarified. However, the use of dpkg-statoverride within a package is yet unclear to me. You don't ever use it to set permissions in maintainer scripts; see below. With suidregister, we used to: - override setuid/setgid when building the package (debian/rules) - readd setuid/setgid permissions in the postinst with suidregister - remove setuid/setgid permissions in the postrm with suidunregister Almost. We asked suidregister to set (not necessarily add) the setuid/setgid permissions as required. suidregister would note the package maintainer's request and compare it to its existing database. If there was a manual override present, the maintainer's version would be ignored, otherwise it would be used. Can someone tell me what's exactly to be done now with dpkg-statoverride? Can we embbed setuid/setgid executables in the package and dpkg-statoverride will be used only to override permissions to non-setuid/non-setgid ? In the new setup, we put the most usual version in the .deb; if the program would normally be run setuid/setgid then that is what should be in the .deb; if it is normally run non-setuid/non-setgid, then that should be put in the .deb. Should the sysadmin wish to change things from the default, they run the dpkg-statoverride --update --add command, and then that becomes the default from then on. Dpkg will automatically examine the statoverride file every time a package is installed to see whether there are any local statoverrides; you don't need to do anything in your maintainer scripts any longer. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Could someone clarify dpkg-statoverride please? (Was Re: dpkg-statoverride and creating users in postinst)
Everything is clear now. Thanks a lot for these explanations. -- Jérôme Marant [EMAIL PROTECTED] --- Debian Activity Page: http://jerome.marant.free.fr/debian ---
