Hi,
and -no-.
If you put fixperms after suidregister, you undo its work. Also, fixperms
establishes a "perm baseline" that you modify by adding calls to chown and
chmod after fixperms and before suidregister. You make this change, you break
that. It works nicely :) Don't break it :) It's not broken, and this is not
a fix.
Also note that suidregister takes care of the bits: it records the desired
state (which should be altered as desired between fixperms and suidregister)
and then normalizes the bits.
> Date: Sat, 27 Nov 1999 18:15:04 GMT
> To: Brian May <[EMAIL PROTECTED]>
> cc: debian-mentors@lists.debian.org,
> Debian bug reports <[EMAIL PROTECTED]>
> From: Julian Gilbey <[EMAIL PROTECTED]>
> Subject: debhelper: dh_fixperms should come after dh_suidregister (was: Re:
> set
> ***gid stuff)
This is the correct order. Look at what dh_suidregister does. See above.
> Package: debhelper
> Version: 2.0.74
>
> On Sat, Nov 27, 1999 at 12:26:50PM +1100, Brian May wrote:
> > >>>>> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes:
> >
> > Julian> Note the dh_fixperms is at the end of this sequence, and
> > Julian> must be: Debian packages should not ship with any special
> > Julian> bits set (except for symlinks and directories).
Remember: dh_suidregister does the right thing. -look- at it. It records
the appropriate state (or tries to: it has some broken behavior, but this
isn't it) and then normalizes the appropriate bits. When the package is
later installed, suidregister is called and informed of the situation
assuming suidregister is installed. Then the bits are altered to the
desired state.
It works like this:
dh_fixperms # all permissions in the package are normalized: any suid and such
# is killed off.
# now, you have a baseline under which no setuid or other permission anomalies
# exist. You raise over that baseline by altering permissions to taste.
chmod 4755 mythingie
chown some:one mythingie
# after you have made all the changes you want, you have this situation:
# baselined by dh_fixperms, changes have been made to permissions. Hence,
# the only changes to those permissions to "anomalous" states are the changes
# you purposely made.
dh_suidregister # this creates a database of sorts in the form of commands
# in the postinst. It does this by noticing anomalous
# (or non-policy) conditions in the package files.
# For each such condition:
# - writes a stanza in postinst that either registers
# said condition or directly alters the file
# such that the permissions are as authored
# - alters the package's copy of the file (in debian/tmp)
# to follow policy (i.e., no setuid, etc)
And yes, dh_suidregister is broken for certain cases, but changing the
order as this msg suggests is not the correct solution.
You can always do:
dh_fixperms
(make your alterations here)
dh_suidregister
dh_fixperms
but note that the proper behavior of dh_suidregister is to fix the perms
as it notices them and records onto the postinst what it should do.
If it does not notice it, then you should alter the arguments to
dh_suidregister so as to force it to notice.
If it does not notice, then it might not have written the postinst so
as to make the permissions as authored.
If it does notice but does not set the perms appropriate to policy on
files in packages (as opposed to as authored), that is broken. But the
fix is to the inner workings of dh_suidregister, not to the call order.
-Jim
---
Jim Lynch Finger for pgp key
as Laney College CIS admin: [EMAIL PROTECTED] http://www.laney.edu/~jim/
as Debian developer: [EMAIL PROTECTED] http://www.debian.org/~jwl/
