[gentoo-dev] user management mitigation

[gentoo-dev] user management mitigation

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

with the previously proposed/accepted GLEP 27 stalled, i'm looking into 
mitigating the current suckiness of enew{user,group}/egetent.  the first step 
is simple: let's split these funcs out of eutils.eclass and into a dedicated 
eclass.  this makes it trivial for people externally to override the 
functionality and hook into whatever craziness they want.

eutils.eclass will inherit this new eclass directly (for the foreseeable 
future), so there's no need for tree-wide update bonanzas.

suggested name: euser.eclass
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] user management mitigation

[Alexandre Rostovtsev]

On Thu, Oct 20, 2011 at 4:47 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> with the previously proposed/accepted GLEP 27 stalled, i'm looking into
> mitigating the current suckiness of enew{user,group}/egetent.  the first step
> is simple: let's split these funcs out of eutils.eclass and into a dedicated
> eclass.  this makes it trivial for people externally to override the
> functionality and hook into whatever craziness they want.

Wishlist item for the new eclass: a function that allows adding an
existing user (that had previously been created by enewuser) to a
particular group without dropping any other groups that the user is
already in. Would be very useful for gdm-3.2.

-Alexandre

Re: [gentoo-dev] user management mitigation

[Brian Harring]

On Thu, Oct 20, 2011 at 04:47:55PM -0400, Mike Frysinger wrote:
> with the previously proposed/accepted GLEP 27 stalled, i'm looking into 
> mitigating the current suckiness of enew{user,group}/egetent.  the first step 
> is simple: let's split these funcs out of eutils.eclass and into a dedicated 
> eclass.  this makes it trivial for people externally to override the 
> functionality and hook into whatever craziness they want.
> 
> eutils.eclass will inherit this new eclass directly (for the foreseeable 
> future), so there's no need for tree-wide update bonanzas.

Whatever the eclass name, the API it exports should be controlled 
carefully so that when g27 lands, we can just swap the functionality 
directly in- just have the eclass watch for a magic value 

Either way, sounds good.
~brian

Re: [gentoo-dev] user management mitigation

[Leho Kraav]

Mike, can you offer a tip on how to "trivially hook into whatever craziness" with the help of user.eclass? My goal is to have regular enewuser and enewgroup work for ROOT=/xyz. But I don't currently have a clue what would *not* be a horribly broken way to do this. It seems like I perhaps should write some additional code for handling ROOT into user.eclass and stick it in my overlay?

Re: [gentoo-dev] user management mitigation

[Leho Kraav]

So after a reading through a bunch of stuff [1][2][3][4][5], what I'm going to do for the goal above is:

 * move to sys-apps/shadow trunk [6]
 * fork my own user.eclass from v1.17, modify it to use --root $ROOT when calling shadow stuff
 * stick my user.eclass into myoverlay/eclass/
 * # echo "lkraav" > myoverlay/profiles/repo_name
 * # echo "[DEFAULT]\neclass-overrides = lkraav" > /etc/portage/repos.conf
 * # echo "PORTAGE_RSYNC_EXTRA_OPTS=\"--exclude=/metadata/cache\"" >> /etc/make.conf
 * # rm -rf /usr/portage/metadata/cache
 * # echo "emerge --regen" >> /etc/cron.weekly/09-my-portage-update-script
 * subscribe to atom feed of portage user.eclass changes, merge stuff until sys-apps/shadow-4.1.4.5 surfaces and maybe main tree user.eclass gets patched to use --root
 * try to achieve clamlike happiness with this setup

Anything particularly important I'm missing? Is this the rightish way to do it?

 [1]: https://forums.gentoo.org/viewtopic-p-5877500.html
 [2]: https://groups.google.com/forum/#!topic/linux.gentoo.dev/FYJ4g5IryIw/discussion
 [3]: https://alioth.debian.org/tracker/index.php?func=detail&aid=312407&group_id=30580&atid=411480
 [4]: https://bugs.gentoo.org/show_bug.cgi?id=53269'
 [5]: http://www.linux-archive.org/gentoo-embedded/295178-emerge-root-users-not-created.html
 [6]: https://bugs.gentoo.org/show_bug.cgi?id=393073

Re: [gentoo-dev] user management mitigation

[Mike Gilbert]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

On 12/04/2011 09:44 AM, Leho Kraav wrote:
> So after a reading through a bunch of stuff [1][2][3][4][5], what I'm going to do for the goal above is:
> 
>  * move to sys-apps/shadow trunk [6]
>  * fork my own user.eclass from v1.17, modify it to use --root $ROOT when calling shadow stuff

I think a possible problem here would be a build system that uses
user/group id's from the host root during the build process. If any
packages do this, it is possible that the users/groups would need to be
added in both /etc/passwd and ${ROOT}etc/passwd.

>  * stick my user.eclass into myoverlay/eclass/
>  * # echo "lkraav" > myoverlay/profiles/repo_name
>  * # echo "[DEFAULT]\neclass-overrides = lkraav" > /etc/portage/repos.conf
>  * # echo "PORTAGE_RSYNC_EXTRA_OPTS=\"--exclude=/metadata/cache\"" >> /etc/make.conf
>  * # rm -rf /usr/portage/metadata/cache
>  * # echo "emerge --regen" >> /etc/cron.weekly/09-my-portage-update-script

That sounds about right.

>  * subscribe to atom feed of portage user.eclass changes, merge stuff until sys-apps/shadow-4.1.4.5 surfaces and maybe main tree user.eclass gets patched to use --root

We have one of those!?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] user management mitigation

[Zac Medico]

On 12/04/2011 06:44 AM, Leho Kraav wrote:
> So after a reading through a bunch of stuff [1][2][3][4][5], what I'm going to do for the goal above is:
> 
>  * move to sys-apps/shadow trunk [6]
>  * fork my own user.eclass from v1.17, modify it to use --root $ROOT when calling shadow stuff
>  * stick my user.eclass into myoverlay/eclass/
>  * # echo "lkraav" > myoverlay/profiles/repo_name
>  * # echo "[DEFAULT]\neclass-overrides = lkraav" > /etc/portage/repos.conf
>  * # echo "PORTAGE_RSYNC_EXTRA_OPTS=\"--exclude=/metadata/cache\"" >> /etc/make.conf
>  * # rm -rf /usr/portage/metadata/cache
>  * # echo "emerge --regen" >> /etc/cron.weekly/09-my-portage-update-script

If user.eclass is the only eclass you override, then since user.eclass
doesn't modify metadata variables like *DEPEND or IUSE, it's safe to use
metadata/cache from rsync.
-- 
Thanks,
Zac
ta

Re: [gentoo-dev] user management mitigation

[Leho Kraav]

On Sunday, December 4, 2011 4:50:02 PM UTC+2, Leho Kraav wrote:
>
>  * fork my own user.eclass from v1.17, modify it to use --root $ROOT when calling shadow stuff

So first thing I'm running into is replacing getent with something that supports chrooting. Only immediate thought for users is using passwd --status. For groups I'm not even seeing anything obvious to use.

Any thoughts?