Summary: | api layer to enforce uid/gid policy | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Seemant Kulleen (RETIRED) <seemant> |
Component: | [OLD] Core system | Assignee: | SpanKY <vapier> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | azarah, bugs+gentoo, chewi, dams, h3y, jrray, m.debruijne, mark, max, mkeadle, mr_bones_, pauldv, roughneck, scandium, vapier, wschlich |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Seemant Kulleen (RETIRED)
2002-10-02 00:58:34 UTC
Hi, I'l the libconf coder, see here for doc : http://www2.damz.net/files/libconf_doc.html 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. 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? Owen 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 =) 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 ;/ 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. matt, your pam expertise needed... 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"; Hello 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. Reassigning bugs due to lack of time. we need to have the eid_database in rsync for this to happen then let us create it Can anybody summarize what should be done and how? Give a little sorted todo list 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 enew{user,group} finally, we put in a policy that says 'if you want a new user/group you must use enew{user,group}' 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. max, that's the way I'm leaning as well 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 USERDEPEND="apache" GROUPDEPEND="apache" 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, Stu -- 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.group,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 | uniq app-admin/amanda app-admin/setools app-games/quake3 app-misc/nomadii-utils dev-db/mysql dev-db/xindice dev-lisp/common-lisp-controller media-sound/rplay media-sound/speechd net-analyzer/nagios-core net-analyzer/nagios-plugins net-analyzer/snort net-dialup/gnokii net-dialup/mgetty net-dns/djbdns net-dns/ldapdns net-fs/sfs net-ftp/jftpgw net-ftp/proftpd net-im/jabber-server net-mail/amavis net-mail/amavisd-new net-mail/clamav net-mail/cmd5checkpw net-mail/cyrus-imapd net-mail/mailman net-mail/nullmailer net-mail/pop3vscan net-mail/postfix net-mail/qmail-ldap net-mail/vpopmail net-mail/xmail net-misc/dhcp net-misc/ntp net-misc/nut net-misc/openssh net-misc/radvd net-misc/taylor-uucp net-nds/openldap net-news/inn net-p2p/freenet net-p2p/mldonkey net-www/apache net-www/fnord net-www/jboss net-www/middleman net-www/orion net-www/privoxy net-www/publicfile net-www/resin net-www/resin-ee net-www/tomcat net-zope/zope sys-apps/lufs sys-apps/selinux-small sys-apps/shadow sys-apps/slocate sys-apps/tcb sys-apps/usermode-utilities sys-kernel/gs-sources sys-kernel/usermode-sources x11-themes/qinx 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 ? 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: http://www.gentoo.org/proj/en/gentoo-alt/macos-1.xml 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. so now we just need PPAM so that PAM can be plugged in or not... ;-) Spanks, *great* glep -- thanks so much for working on that http://www.gentoo.org/proj/en/glep/glep-0027.html bam like fried chicken *** Bug 56130 has been marked as a duplicate of this bug. *** this GLEP is a great idea, seems to have stalled.. can we get a status?? chicken? cow! |