In defense of Suidmanager
I think dpkg is the wrong place to put the management of those bits
because the suidbits should be under the control of the maintainer. The
application might decide on installation how to install the package and
thus it would be good if the permissions be under the control of the
maintainer in the scripts.
Some form of script interface is needed which the envisioned dpkg solution
would not provide.
Another argument for /etc/suid.conf is the very desirable feature to have
one file which lists ALL files that could be potential security risks.
The system administrator has it much easier if he can just edit a file to
set up his local policy regarding these issues.
Having the permissions not in /etc/suid.conf means that the sysadmin needs
a tool to generate an overview about suid binaries and their status. And
then the sysadmin has to starts a series of chmods and chowns to set up
the permissions. Suidmanager makes the task much simpler.
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: