On Thu, Jul 03, 2003 at 12:42:23PM +0200, Hubert Feyrer wrote:
> 
> audio/xmcd/Makefile:SPECIAL_PERMS=           ${ARCHBIN}/cda ${_SETUID_ROOT}
> audio/xmcd/Makefile:SPECIAL_PERMS+=          ${ARCHBIN}/xmcd ${_SETUID_ROOT}
> comms/minicom/Makefile:SPECIAL_PERMS=        ${PREFIX}/bin/minicom uucp dialer 4755
> print/cups/Makefile:SPECIAL_PERMS=           ${PREFIX}/bin/lppasswd ${CUPS_USER} ${CUPS_GROUP} 4755
> x11/eterm/Makefile:SPECIAL_PERMS=            ${PREFIX}/bin/Eterm ${SETUID_ROOT_PERMS}
> x11/kdebase3/Makefile:SPECIAL_PERMS+=        ${PREFIX}/bin/konsole_grantpty  ${_KDE_SETUID_ROOT}
> x11/kdebase3/Makefile:SPECIAL_PERMS+=        ${PREFIX}/bin/kcheckpass        ${_KDE_SETUID_ROOT}
> x11/kdebase3/Makefile:SPECIAL_PERMS+=        ${PREFIX}/bin/ksysguardd        ${_KDE_SETUID_ROOT}
> x11/kterm/Makefile:SPECIAL_PERMS=            ${PREFIX}/bin/kterm ${_SETUID_ROOT}
> x11/rxvt/Makefile:SPECIAL_PERMS=             ${PREFIX}/bin/rxvt ${SETUID_ROOT_PERMS}
> x11/xlockmore-lite/Makefile:SPECIAL_PERMS=   ${PREFIX}/bin/xlock ${SETUID_ROOT_PERMS}
> x11/xlockmore/Makefile:SPECIAL_PERMS=        ${PREFIX}/bin/xlock ${SETUID_ROOT_PERMS}
> 
> I guess these should be nuked from heaven. All of them.
> (Yes, that's all the hits for a grep on SPECIAL_PERMS in pkgsrc Makefiles)

In the examples you've given above, the one for cups falls under the
scenario I've given, where the binary package won't necessarily do the
right thing (except by accident) because lppasswd needs to be owned by
a user that may be created by the binary package during installation.
I think the kdebase[23] packages used to not necessarily set the
correct mode permissions on their root-setuid binaries, so we forced
them to be the correct mode permissions using SPECIAL_PERMS.  I'm not
sure whether this has changed or not.  Although you can certainly just
fix the permissions in a post-install target and rely on tar/pax to do
the right thing, I personally prefer using SPECIAL_PERMS because you
are told during post-installation that you are installing root-setuid
binaries.

For the other packages that list root-setuid binaries, the root user
and group are typically well-known and fixed IDs, so they could be
removed.  However, keeping these lines allows for setups where, e.g.
ROOT_USER or ROOT_GROUP is redefined by the package builder.  I don't
tout this as a common case, and I'm not going to object if you wish
to remove these lines.

	Cheers,

	-- Johnny Lam <jlam@netbsd.org>