Re: a nitpicky reading of policy
On Thu, Dec 02, 1999 at 03:41:34PM -0800, Joey Hess wrote:
> * "Every package must have exactly one maintainer at a time." This statement
> is violated by so many packages (including dpkg) that it should be removed.
I think it's being interpreted as "one maintainer email address". But
you're right, the language should be cleaned up, as in a number of
cases that email address is a mailing list.
> * This seems self-contradictory. Are you supposed to remove the created
> directories or not?
>
> However, the package should create empty directories below
> `/usr/local' so that the system administrator knows where to place
> site-specific files. These directories should be removed on package
> removal if they are empty.
>
> Note, that this applies only to directories _below_ `/usr/local', not
> _in_ `/usr/local'. The directory `/usr/local' itself may only contain
> the sub-directories listed in FHS, section 4.6. However, you may
> create directories below them as you wish. You may not remove any of
> the directories listed in 4.6, even if you created them.
I think this means that if there's a /usr/local/lib and you respect a
/usr/local/lib/gobble then you should create this directory. But if
/usr/local/lib doesn't exist you shouldn't.
> * "must not overwrite or otherwise mangle the user's
> configuration without asking, must not ask unnecessary questions
> (particularly during upgrades), and otherwise be good citizens."
>
> Just to remove the tiny shred of ambiguity from this sentance, I'd say
> change the end to "and must otherwise be ..."
In my opinion, that's a worthwhile bit of ambiguity. Basically, it's
asking for no pathological behavior. And that's all too easy to do with
automated handling of configuration files.
> * "Do not arrange that the system administrator can only reconfigure the
> package to correspond to their local security policy by changing the
> permissions on a binary. Ordinary files installed by `dpkg' (as opposed to
> conffiles and other similar objects) have their permissions reset to the
> distributed permissions when the package is reinstalled. Instead you should
> consider (for example) creating a group for people allowed to use the
> program(s) and making any setuid executables executable only by that group."
>
> This paragraph seems to be unaware of suidregister. Perhaps it should
> mention it as an alternative.
Hmm... Points to consider:
(1) suidmanager is optional,
(2) dpkg doesn't directly support suidregister
(3) using a consistent scheme (group access, in this case)
has other nice properties.
However, it is worth thinking through.
Good work, Joey.
--
Raul
Reply to: