Summary: | enewgroup uses GID_MIN/GID_MAX to generate system GIDs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Hogan <chris.c.hogan> |
Component: | Eclasses | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | a3li, anigel, des, evert.gentoo, gentoo, ljubo108, mbartoszkiewicz, prote, remi |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | eutils.eclass enewgroup patch to use SYS_GID_MIN/MAX |
Description
Christopher Hogan
2009-03-15 13:59:45 UTC
Created attachment 185077 [details, diff]
eutils.eclass enewgroup patch to use SYS_GID_MIN/MAX
A lot of people including me have this problem, and indeed, -r or --system should be used to add a system group, see man groupadd. Thanx for writing a patch Christopher! I hope this one will be fixed in portage soon since I don't like to change gids manually (including a find / -group <oldgid> -print0 | xargs -0r chgrp -hc <newgid>) for every new added system group. Also seeing this on fresh installs. At some point in the past, this behaved correctly, because my UID/GID is 1000/1000. Now I have to change the IDs on all these extra groups Portage created. :/ Hi, Same problem here, which led me to spend too much time on this. This can cause very strange behaviour on systems using alternate auth backends, such as NIS or LDAP, and, what is more, could drive to security holes, since some regular users of the alternate backends can belong to the same "distant" groups that some running daemons (with "local" groups with the same gid) ! Maybe severity of this bug should be changed ? As I see it, bug #264519 is a duplicate of this one, but also includes a request for enewuser. I already put 10 votes on that bug. base-system, what is the status here? Neither groupadd nor useradd in current eclass use -r option. This means that currently, and in the last months, users have installed systems on which some daemons are running with UIDs / GIDs which are commonly affected to users (by convention, uid > 1000 are for users, as gid > 100 are for user groups). If such a system is used with a distant authentication backend (LDAP / NIS / MySQL / PostGreSQL...), there are good chances that this backend used the convention to create user accounts with uids and gids already used in local by daemons. When such a user logs in, he can interact with these daemons easily (start / stop / restart / and far more) . This bug is not only a bug, it can be a HUGE security hole too ! It's now more than one year ago this bug report was created. Any chance this bug will be solved in 2010 ? 3 months later... Maybe someone can take a few seconds to add 17 bytes to eutils.eclass and solve this problem ? +1 on it, but we need to make extremely sure that it's not going to generate GIDs that conflict with other static ones (really however, all system UID/GIDs should be static). That's why I believe we've got GLEP 27, however the implementation in there is pretty miserable. I've actually committed this for now after discussing it a bit with Chainsaw. If I remember when I discussed something like this with Mike a while back he said we really should just implement GLEP 27 instead. But hey I could be wrong. If there's pieces from this, I'll pick them up. Hi Thank you very much for solving this. It will simplify my life a lot ;-). |