Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 8634 - api layer to enforce uid/gid policy
Summary: api layer to enforce uid/gid policy
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High critical (vote)
Assignee: SpanKY
: 56130 (view as bug list)
Depends on:
Reported: 2002-10-02 00:58 UTC by Seemant Kulleen (RETIRED)
Modified: 2012-07-29 21:22 UTC (History)
16 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Seemant Kulleen (RETIRED) gentoo-dev 2002-10-02 00:58:34 UTC
OK lads, let this bug be a meeting place of sorts.
Comment 1 dams (RETIRED) gentoo-dev 2002-10-02 02:53:41 UTC
Hi, I'l the libconf coder, see here for doc :

libconf is the gentoo configuration file abstraction layer. It's not finished,
but is already kind of useable. Among the stuff built over it is an equivalent
to debconf, let's call it gentooconf here. It should help interactive post
package configuration by abstracting the configuration file accsess. It might be
interesting to see if libconf can meets our needs on this subject. 
Comment 2 Owen Stampflee (RETIRED) gentoo-dev 2002-10-02 12:19:05 UTC
Well, from my talks with mjc, we shouldnt be touching /etc/{passwd, group} as
remote auth systems such as LDAP do not have such files. Thoughts? Could we
extend libconf to talk to PAM for such things and fall back to /etc/{passwd,
group} if PAM is not there?

Comment 3 Michael Cohen (RETIRED) gentoo-dev 2002-10-02 23:31:53 UTC
We should be using PAM to check authentication, gid, uid, and friends.  It's best to provide auth-system users with the ability to not have /etc/{group,passwd}.  currently I have to make a cronjob to export my UIDs and GIDs from ldap, and let me tell you it's a pain, plus on my testbed of 100 boxes at my school, man is it a network load when you fresh install a machine.  We'd need to create standard /etc/passwd and /etc/groups for *adding* users though, or we'd need to inform people for whom [ -f "/etc/group" -f "/etc/password" ] is not true to add account[s] manually.  I'd prefer doing both, as pam would use fallback auth.  Thanks =)
Comment 4 Martin Schlemmer (RETIRED) gentoo-dev 2002-10-03 13:51:22 UTC
I guess this brings up how much we want to leave up to the user type of
arguments again.  Just to toss a spanner in the works ;/
Comment 5 Owen Stampflee (RETIRED) gentoo-dev 2002-10-06 15:47:38 UTC
I cant seem to connect with dams so my I'll post my questions here, can libconf 
talk to PAM and talk to /etc/{passwd, group} specifically? I dont want to have 
to reinvent the wheel and write an util for todo the PAM stuff. 
Comment 6 Seemant Kulleen (RETIRED) gentoo-dev 2002-10-11 08:38:50 UTC
matt, your pam expertise needed...
Comment 7 Michael Cohen (RETIRED) gentoo-dev 2002-10-11 09:10:58 UTC
Here's the deal.  PAM should used explicitly to read and authenticate. 
We shouldn't make changes to PAM with 
What we need to do is this:  Set up documentation for administrators
with a list of *all* the ebuilds that can/should/will use unique usernames.
We should set up variables in make.conf or rc.conf to set the uid/gid at merge 
time.  Because we can't add new [uid,gid]s, if it's necessary to add a seperate 
and unique [uid,gid], we can do that in /etc/[passwd,shadow,group] and warn the 
admin.  We also need some sort of method of contacting the admin (syslog emails 
or something) when we do this other than just print "foo";
Comment 8 dams (RETIRED) gentoo-dev 2002-12-01 06:31:04 UTC

some weeks later than planed, I have a userapi program that is somehow
functional. I will ebuild it. Feel fre to ask me for it if you want to test it.
Comment 9 J Robert Ray 2003-06-26 00:13:21 UTC
Reassigning bugs due to lack of time.
Comment 10 SpanKY gentoo-dev 2003-06-26 04:29:01 UTC
we need to have the eid_database in rsync for this to happen 
Comment 11 Seemant Kulleen (RETIRED) gentoo-dev 2003-06-26 04:35:57 UTC
then let us create it
Comment 12 dams (RETIRED) gentoo-dev 2003-07-03 01:33:42 UTC
Can anybody summarize what should be done and how? Give a little sorted todo list
Comment 13 SpanKY gentoo-dev 2003-07-03 10:46:37 UTC
the eid_database has to be moved into the rsync tree ...

then i have to update enew{group,user}

then all ebuilds that add users/groups have been recoded to use

finally, we put in a policy that says 'if you want a new user/group
you must use enew{user,group}'
Comment 14 Max Kalika (RETIRED) gentoo-dev 2003-07-21 18:48:56 UTC
After we have an eid_database in place, would it make sense to remove all but the very essential usernames/groups from /etc/{passwd,group} and leave it to the ebuilds to create users/groups on demand?  Seems that this would be a lot cleaner.
Comment 15 Seemant Kulleen (RETIRED) gentoo-dev 2003-07-21 18:58:52 UTC
max, that's the way I'm leaning as well
Comment 16 Stuart Herbert (RETIRED) gentoo-dev 2003-07-22 01:50:53 UTC
Just a quick comment to the idea that it should be up to users to create new users 
on their own boxes ... 
That'd be fine, provided users were forced to do this *before* the package merged.  
Some packages need those users/groups in place to chown files and directories.  
That sort of activitiy shouldn't be left up to the user to do post-emerge. 
I'd like to see a way for packages to explicitly export the list of users and groups 
that they create/require.  Something like 
that way, portage can handle creating users/groups that are missing - ebuilds can 
be simplified to assume that the users/groups have been handled elsewhere. 
It also means that scripts can be written to audit a system, and flag up users/groups 
that ebuilds have installed, but which are no longer required (ie emerge -C apache 
could make the 'apache' user no longer required).  I'd certainly find being able to 
audit my hardened machines this way to be very useful. 
Best regards, 
Comment 17 Max Kalika (RETIRED) gentoo-dev 2003-08-27 10:03:28 UTC
Any status on this?  Should this be turned into a GLEP?  In any case, 
we need a plan for converting current things to use the eid_database files. 
Maybe something along the lines of this (this is just a braindump therefore 
very rough and is in no particular order) 
1) move all currently existing UIDs and GIDs from baselayout/{group,passwd} 
   to eid_database/{group,passwd} 
2) move eid_database/{group,passwd} to profiles/{,eid.passwd} 
3) change enewuser/enewgroup to consult with the eid.{group,passwd} files 
   - if a username is found, the UID from there is used 
   - otherwise if the UID is specified as an argument that is used 
     (if it doesn't already exist) 
   - otherwise the next available UID is used 
   (same for groups) 
4) add edeluser/edelgroup to remove users and groups on unmerge as Stuart 
   suggested in comment #16.  this one is tricky because some SLOTed 
   packages share UIDs and some different packages may even share UIDs 
   (i.e. amavis, amavisd-new) and GIDs (i.e. MTAs sharing the mail group). 
5) convert all the current ebuilds to use the new e{new,del}{user,group} 
   system and make sure that all the ebuilds that expect specific usernames 
   and/or groups from baselayout get the appropriate enewuser/enewgroup 
   call in the ebuild file. 
just a quick check for which current ebuilds do user/group management 
revealed the following list: 
# for i in `find . -name '*.ebuild'`; do grep -rl -e useradd -e usermod -e 
enewuser -e groupadd -e enewgroup $i; done | awk -F/ '{print $2"/"$3}' | sort | 
Comment 18 SpanKY gentoo-dev 2003-09-09 10:15:16 UTC
i do like the idea of passing the user handling off to portage ...
like setting a variable which would be a list of users for portage to add, and another variable which would be a list of groups for portage to add ...

this way we dont have to worry that our logic of adding/removing users will screw up SLOTs/etc... since portage will be handling it

only issue i see is, what if we remove a user that still owns files on the system ?  should we remove the user and print a summary of files that have been orphaned as a result ?
Comment 19 Daniel Robbins (RETIRED) gentoo-dev 2003-09-09 18:19:51 UTC
This stuff is an issue for multi-platform support, as on MacOS X netinfo is used to add users. So expect a solution to be crafted for Portage as the MacOS X stuff matures, probably by me. See:
Comment 20 Grant Goodyear (RETIRED) gentoo-dev 2004-01-29 08:03:00 UTC
Also, just to add to the fray, anything that requires PAM is really unacceptable
as some of our users deliberately choose not to use PAM.  Moreover, non-linux
systems also often lack PAM.
Comment 21 Aron Griffis (RETIRED) gentoo-dev 2004-01-29 09:42:57 UTC
so now we just need PPAM so that PAM can be plugged in or not... ;-)
Comment 22 Seemant Kulleen (RETIRED) gentoo-dev 2004-05-29 16:41:36 UTC
Spanks, *great* glep -- thanks so much for working on that
Comment 23 SpanKY gentoo-dev 2004-05-29 21:51:41 UTC

bam like fried chicken
Comment 24 SpanKY gentoo-dev 2004-07-05 08:03:08 UTC
*** Bug 56130 has been marked as a duplicate of this bug. ***
Comment 25 jieryn 2005-12-11 07:43:36 UTC
this GLEP is a great idea, seems to have stalled.. can we get a status??
Comment 26 Wolfram Schlich (RETIRED) gentoo-dev 2008-05-13 16:38:52 UTC
chicken? cow!