Gentoo Archives: gentoo-dev

From: splite-gentoo@××××××××××××××××.edu
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] EID database and entries getting to baselayout
Date: Thu, 29 Jan 2004 22:02:24
Message-Id: 20040129214040.GF7186@sigint.cs.purdue.edu
In Reply to: Re: [gentoo-dev] EID database and entries getting to baselayout by Max Kalika
1 On Thu, Jan 29, 2004 at 11:11:04AM -0800, Max Kalika wrote:
2 > Quoting splite-gentoo@××××××××××××××××.edu:
3 >
4 > Might be my own twisted view, but I can't see the benefit in sharing system
5 > accounts across different boxes. Mysql database, NIS maps, LDAP,
6 > what-have-you, can contain just the _user_ accounts. The remaining system
7 > stuff belongs in /etc/{passwd,group} because different boxes can run
8 > different services.
9
10 Unix doesn't differentiate between system and user accounts (save uid 0).
11 Any line between them is arbitrary and differs by OS and local policy.
12 I remember when only uids under 100 were considered system. Now many
13 systems assume under 1000. (You said under 2000 for your site.) Heck,
14 there's no reason why all the system accounts couldn't be between 5412
15 and 6883.
16
17 Given that system uids are arbitrary, how do you make sure you don't
18 assign the system uid you (or Portage) just stuck in /etc/passwd to a
19 regular user? You... wait for it... put it in the global database.
20
21 > But I suppose legacy is legacy and hard to break away from.
22
23 True, but it's not just about legacy stuff. There's no reason another
24 current OS couldn't pick a different dividing line between system and
25 user uids. All the ones we use do.
26
27 > > It's not really a huge undertaking to provide a switch that lets folks do
28 > > their account management themselves if they need to. I'm not asking that
29 > > ebuilds should automagically know how to update my NIS maps or talk to
30 > > your MySQL server.
31 >
32 > Something like ...
33 >
34 > FEATURES="accounts" (set by default in make.global). When on,
35 > enewuser/enewgroup will happily create the user/group based on eid.*. When
36 > off, enewuser/enewgroup will stop the build process when the user/group
37 > doesn't exist informing the admin to create it ahead of time?
38
39 Right, though I would call it "noaccounts" and leave the current behavior
40 as the default.
41
42 > Lets take it further! Instead of using enewuser/enewgroup, what about
43 > adding two new variables in ebuilds? USERS="user1 user2" and GROUPS="group1
44 > group2". These have to be defined in eid.* databases. When the merge
45 > process starts, the accounts are either created or the build dies (based on
46 > FEATURES="accounts"). This has a side benefit of being tracked per package
47 > in the portage database and these accounts can be removed when the final
48 > version of the package is unmerged (based on the "accounts" feature, of
49 > course). Thoughts from the portage folk?
50
51 This is more than I was asking, but it's not a bad idea.
52
53 --
54 gentoo-dev@g.o mailing list