Ticket #858 (closed defect: wontfix)

Opened 10 years ago

Last modified 8 years ago

discuss server gets random UID

Reported by: jweiss Owned by:
Priority: low Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


installing the debathena-discuss-server package ended up with discuss in the password file using a random UID, and not 32000 (the UID discuss has in hesiod/moira/etc, and the one I expected it to use).

As an aside, the UID assigned happened to conflict with something else in hesiod, but I understand that's a hard problem, and am willing to ignore it.

Change History

comment:1 follow-up: ↓ 2 Changed 10 years ago by andersk

This is the way that all Debian packages handle UIDs, save the very few UIDs that were globally allocated by the Debian project in /usr/share/base-passwd/passwd.master. Is there a special reason that the numeric value of the local discuss UID is important to you?

comment:2 in reply to: ↑ 1 Changed 10 years ago by jweiss

Mostly that I think of moira as the system of record for UIDs and it does have one allocated for discuss. Certainly I wouldn't expect me to get a different UID when logging into a DebAthena? machine, tho I'll certainly admit that theres a difference between a user and a system account. That said, I certainly expect it to work just fine with the random uid.

Assuming this is addressed and not "wontfixed" the gid (5002) should be dealt with too for consistency.

comment:3 Changed 10 years ago by mitchb

I suspect the real difficulty here is that while we could
use the moira-assigned ID safely for discuss on machines
with a metapackage that involves supporting Athena accounts,
forcing it to be a fixed ID that's not allocated by the
base-passwd folks in Debian on a machine with just the -clients
metapackage (or no metapackage) could interfere with whatever
local UID assignment scheme is in use.

It does seem fairly poor to me that it got you an ID that
overlapped with something in moira, though.

comment:4 Changed 10 years ago by jdreed

Is this ticket anything different than #299? I mean, there's nothing really we can do here, right? Local system UIDs are always going to clobber Hesiod ones.

I mean, adduser does support the --uid option, presumably adduser would DTRT if a UID was specified. (As it happens, 32000 is outside the range of both system accounts and user accounts, according to /etc/adduser.conf)

comment:5 Changed 10 years ago by quentin

More generally, on systems which are using Athena accounts, it seems like it would be useful if adduser would check in Hesiod for a user of the same name, and use that uid iff it is not already taken on the local machine. Since NSS_NONLOCAL_IGNORE is set for adduser, this logic should probably be added to the adduser/addgroup wrapper scripts.

It seems like this could also solve the mit group problem at the same time, at least for cluster machines that can arrange for the package to be installed early enough.

comment:6 Changed 10 years ago by andersk

The plan as of  a while  ago was to try to renumber the Moira UIDs and GIDs that are likely to conflict with local ones. Really, that’s the only way we’re going to fully solve this.

Changing the behavior of adduser depending on Hesiod does nothing to help the general problem (most system users and groups exist before Debathena was installed, except possibly on cluster machines where we can (theoretically) fully control the installation process). It also raises unclear security questions.

But as far as I can tell, none of this is a issue for discuss-server in particular.

comment:7 Changed 10 years ago by andersk

See also #299.

comment:8 Changed 8 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix

This is another "Debathena is not Athena 9" bug report, to which the answer is "You're right, it's not." If someone is particularly inclined to modify adduser, they can check if a system user is being added with the same username as a Moira user and print informational text to STDERR, but I don't think any more is necessary. I think we've mostly given up on pretending that daemons should use their entries in Moira.

Documented:  http://kb.mit.edu/confluence/x/bCAYCQ

Note: See TracTickets for help on using tickets.