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/msg00004.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
-----------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
