[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: