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

Re: NMU'ing for wishlist bugs? (aka: intent to NMU bind9)



On Mon, Sep 16, 2002 at 07:17:34PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Sep 16, 2002 at 06:52:02PM +0200, Russell Coker wrote:
> > On Mon, 16 Sep 2002 18:19, Stephen Frost wrote:
> > > No, don't.  If admins want it that way, admins will set it up that way.
> > > By default, since the vast majority of people will *not* have bind
> > > installed, do *not* require everyone have a user they will not use.

> (..)
> > named is more popular than all news servers combined, more popular than 
> > majordomo or uucp ever were (and they are much less popular now), more 
> > popular than msql...  These other programs have their accounts in everone's 
> > /etc/passwd, why not named?

> Reading Bug #95557 and Debian Policy [1] it seems to me that the
> maintainer is not willing to use the 0-99 range (only for
> 'mandatory users') However passwd.master in base-passwd contains the
> following users for services: news, uucp, proxy, postgres, www-data,
> mail, list, and gnats.

> Now, DNS server might be the #2 service in the Internet behind the web
> service (www-data) and probably over mail ('mail', 'list') and many others
> (postgres? gnats?).

Packages don't get their users added to base-passwd by being more
*popular*, but by being more *broken*.  The relevant section of Policy is
10.2.1:

  Some user ids (UIDs) and group ids (GIDs) are reserved globally for use
  by certain packages. Because some packages need to include files which
  are owned by these users or groups, or need the ids compiled into
  binaries, these ids must be used on any Debian system only for the
  purpose for which they are allocated. This is a serious restriction,
  and we should avoid getting in the way of local administration
  policies. In particular, many sites allocate users and/or local system
  groups starting at 100.

  Apart from this we should have dynamically allocated ids, which should
  by default be arranged in some sensible order, but the behavior should
  be configurable.

There is no real reason why bind would need a statically-allocated uid;
it is not broken software that needs to know its numeric uid at compile
time, nor should any of the files shipped with bind be owned by user
'named'.  The only justification seems to be administrative convenience,
which does not justify consuming a uid from our very limited (0-99) pool.

> I wonder: if you allocate the 'bind' user dynamically (should probably be
> 'named' better) how are nameservers going to share name zone
> configuration? I wonder how would I need to switch from 'bind' to 'djbdns'
> or 'maradns'.

Assuming this was a legitimate concern (other posts have pointed out why
config files should not be owned by user 'named'), the package system
still protects you from such errors.  The username and the config files
should both be removed at package purge time, so you would never have
config files without also having a user for them.

> If you do not agree with me here, in any case bind should use 'adduser
> --system' Right?

Absolutely.

Steve Langasek
postmodern programmer

Attachment: pgpeUqnUUTWTN.pgp
Description: PGP signature


Reply to: