carving out board/project specific uid/gid spaces

[Mike Frysinger]

atm, we're largely forcing people to register user accounts in eclass-overlay/.  this is because we want to avoid collisions in the uid/gid namespace.

what if we carved out a space like 2000-2999 for boards/projects to do whatever they like ?  this way for accounts that only show up in a single project, they don't have to post changes to the common overlay to get approved.

-mike

[Prathmesh Prabhu Chromium]

- pro: there are currently lots of users in all products that are not needed (moblab has a whole bunch that nobody else ever needs)

- con: I'd expect duplication sooner or later. 

    A: Oh, I need to run apache, let's add a board-specific-user. Adds user apache

    6 months later, B: Oh I want to run apache, let's add a board-specific-user,  does't check other boards, adds user apache.

- con: Corollary of above, this will make stacking overlays harder to use. A similar problem exists today with virtual ebuild overrides. We don't have a great story around how baseborads/projects etc should version their overlays. The leaf overlay writers end up hacking the ebuild versions to get the one they want.

.... notice how I haven't suggested any solutions above? ;)

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Mike Frysinger]

we could make the user eclass reject accts that show up with diff ids.  it already has to stack everything itself.

-mike

[Mattias Nissler]

Do we have a specific reason to allow stacking for uid/gid allocation other than it being awkward to carry uids/gids that we're not using? Unless there's some more substantial justification, you'll have to weigh the added complexity for people to understand how to manage uid/gid allocations against the slight benefit of cleaner separation in the repository. I'd personally lean towards keeping it simple if there's no strong reason for breaking it up.

[Mike Frysinger]

we want account lookups to walk all the overlays so boards can declare accounts and not have to modify central locations.  this is a general goal we have -- be able to do a build of CrOS and the only thing you need is your own board overlay.

as a fallout of that, we support overriding accounts.  originally we didn't have a strong sense for what it would be good for, but we've seen it used to control the login shell (CrOS defaults to /bin/bash, but embedded systems frequently wants /bin/sh), and for adjusting the supplemental groups list.

wrt making people understand uid/gid allocation, they already need to know how to do that ... they want to create an account, the question becomes "which directory do we create it in".

by carving out a specific range of ids, it satisfies our goal of supporting board isolation.

as a sanity check, i'll extend the logic to make sure uid/gid don't change.  i don't think people want to do this, so if it comes up, it's much more likely it's by accident.  and if it's on purpose, then too bad!

-mike

[Mattias Nissler]

On Mon, May 22, 2017 at 10:09 PM, Mike Frysinger <vap...@chromium.org> wrote:

we want account lookups to walk all the overlays so boards can declare accounts and not have to modify central locations.  this is a general goal we have -- be able to do a build of CrOS and the only thing you need is your own board overlay.

as a fallout of that, we support overriding accounts.  originally we didn't have a strong sense for what it would be good for, but we've seen it used to control the login shell (CrOS defaults to /bin/bash, but embedded systems frequently wants /bin/sh), and for adjusting the supplemental groups list.

wrt making people understand uid/gid allocation, they already need to know how to do that ... they want to create an account, the question becomes "which directory do we create it in".

by carving out a specific range of ids, it satisfies our goal of supporting board isolation.

... but only if you don't inherit further from boards overlays (i.e. only use the private uid/gid range in the leave nodes of the inheritance graph).

 

as a sanity check, i'll extend the logic to make sure uid/gid don't change.  i don't think people want to do this, so if it comes up, it's much more likely it's by accident.  and if it's on purpose, then too bad!

OK, that sounds useful. Note that I'm not opposed to more sophisticated uid/gid allocation mechanisms - from the cases I've been involved with it just doesn't seem like there's a pressing need for it.

[Mike Frysinger]

On Tue, May 23, 2017 at 5:02 AM, Mattias Nissler <mnis...@chromium.org> wrote:

On Mon, May 22, 2017 at 10:09 PM, Mike Frysinger <vap...@chromium.org> wrote:

we want account lookups to walk all the overlays so boards can declare accounts and not have to modify central locations.  this is a general goal we have -- be able to do a build of CrOS and the only thing you need is your own board overlay.

as a fallout of that, we support overriding accounts.  originally we didn't have a strong sense for what it would be good for, but we've seen it used to control the login shell (CrOS defaults to /bin/bash, but embedded systems frequently wants /bin/sh), and for adjusting the supplemental groups list.

wrt making people understand uid/gid allocation, they already need to know how to do that ... they want to create an account, the question becomes "which directory do we create it in".

by carving out a specific range of ids, it satisfies our goal of supporting board isolation.

... but only if you don't inherit further from boards overlays (i.e. only use the private uid/gid range in the leave nodes of the inheritance graph).

we discourage boards inheriting boards because it leads to collisions already

i'm thinking of this space being used by projects mostly, and a few boards after that.  there will be collisions between boards and projects, but boards already know they need to coordinate with the projects they inherit, so i don't think that'll be a problem.

as a sanity check, i'll extend the logic to make sure uid/gid don't change.  i don't think people want to do this, so if it comes up, it's much more likely it's by accident.  and if it's on purpose, then too bad!

OK, that sounds useful. Note that I'm not opposed to more sophisticated uid/gid allocation mechanisms - from the cases I've been involved with it just doesn't seem like there's a pressing need for it.

i'm looking at it as a trend ... with the derivative projects (of which we've got at least 4, and i mean projects, not boards), there's been need for accounts that'll never show up on Chromebooks because the accounts are only used by packages in those project/board overlays.  Jorge has been looking at improving the security autotests so we don't fail with new unknown accounts (as long as they're isolated ... i.e. they aren't part of any other groups) which means we should be able to lower the friction for adding new accounts.  in an ideal world, just about every process would be a diff uid/gid :).

[Jorge Lucangeli Obes]

On Tue, May 23, 2017 at 3:52 PM, Mike Frysinger <vap...@chromium.org> wrote:

On Tue, May 23, 2017 at 5:02 AM, Mattias Nissler <mnis...@chromium.org> wrote:

On Mon, May 22, 2017 at 10:09 PM, Mike Frysinger <vap...@chromium.org> wrote:

we want account lookups to walk all the overlays so boards can declare accounts and not have to modify central locations.  this is a general goal we have -- be able to do a build of CrOS and the only thing you need is your own board overlay.

as a fallout of that, we support overriding accounts.  originally we didn't have a strong sense for what it would be good for, but we've seen it used to control the login shell (CrOS defaults to /bin/bash, but embedded systems frequently wants /bin/sh), and for adjusting the supplemental groups list.

wrt making people understand uid/gid allocation, they already need to know how to do that ... they want to create an account, the question becomes "which directory do we create it in".

by carving out a specific range of ids, it satisfies our goal of supporting board isolation.

... but only if you don't inherit further from boards overlays (i.e. only use the private uid/gid range in the leave nodes of the inheritance graph).

we discourage boards inheriting boards because it leads to collisions already

i'm thinking of this space being used by projects mostly, and a few boards after that.  there will be collisions between boards and projects, but boards already know they need to coordinate with the projects they inherit, so i don't think that'll be a problem.

as a sanity check, i'll extend the logic to make sure uid/gid don't change.  i don't think people want to do this, so if it comes up, it's much more likely it's by accident.  and if it's on purpose, then too bad!

OK, that sounds useful. Note that I'm not opposed to more sophisticated uid/gid allocation mechanisms - from the cases I've been involved with it just doesn't seem like there's a pressing need for it.

i'm looking at it as a trend ... with the derivative projects (of which we've got at least 4, and i mean projects, not boards), there's been need for accounts that'll never show up on Chromebooks because the accounts are only used by packages in those project/board overlays.  Jorge has been looking at improving the security autotests so we don't fail with new unknown accounts (as long as they're isolated ... i.e. they aren't part of any other groups) which means we should be able to lower the friction for adding new accounts.  in an ideal world, just about every process would be a diff uid/gid :).

To follow up on this, the change to the security Autotest test has landed, so if we were waiting on that to make it easier to add new "daemon" accounts, we might want to do it now.