Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Vadim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 30 May 2003 17:18, Grant Goodyear wrote:
> > In principle packages should never depend on any fixed user id.
> > They should look at the passwd database for their uid. The only
> > exception is root which has a predefined userid.
>
> I believe that Mr. Lesser is asking how one decides on uid/gid's
> for new packages that should run as something other than root.
> (For example, apache runs as apache.apache, which maps to uid=81
> and gid=81, and those numbers are defined in the /etc/passwd file
> that's part of baselayout.)

How about fixing the system? For example something like this:

useradd foo
FOO_UID=`awk -F: '$1 == "foo" {printf $3}' /etc/passwd`
FOO_GID=`awk -F: '$1 == "foo" {printf $4}' /etc/passwd`

I've just started at trying to make ebuilds but I suppose this could
be put somewhere in an eclass.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+15fLvCkUtBccqkoRAgTdAKCoxbX3qhh7ZuykpHocE1XqYPCazwCdFt7y
iQP2BpHVxX7CDWxjKcPZDl4=
=lRYI
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Assigning unique system uid/gid for new ebuild

[Martin Lesser]

While writing an ebuild for nullmailer I would like to know how to
determine an unique uid/gid (nullmail/nullmail) which I need in the
script if I don't want to patch the Makefile.

Grepping through other ebuild's I saw that there are several packages
which also use useradd/groupadd with a given id (i.e. postgres=70).

Who assigns these ids used in several other ebuild's where system users
are needed?  How can I prevent id collisions without grepping through
other ebuild-files?

Or should I omit defining sys-users with a fixed id given?

TIA, Martin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 913 bytes --]

On Friday 30 May 2003 16:03, Martin Lesser wrote:
> While writing an ebuild for nullmailer I would like to know how to
> determine an unique uid/gid (nullmail/nullmail) which I need in the
> script if I don't want to patch the Makefile.
>
> Grepping through other ebuild's I saw that there are several packages
> which also use useradd/groupadd with a given id (i.e. postgres=70).
>
> Who assigns these ids used in several other ebuild's where system users
> are needed?  How can I prevent id collisions without grepping through
> other ebuild-files?
>
> Or should I omit defining sys-users with a fixed id given?

In principle packages should never depend on any fixed user id. They should 
look at the passwd database for their uid. The only exception is root which 
has a predefined userid.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Martin Lesser]

Paul de Vrieze <pauldv@gentoo.org> writes:

> On Friday 30 May 2003 16:03, Martin Lesser wrote:
> > Who assigns these ids used in several other ebuild's where system users
> > are needed?  How can I prevent id collisions without grepping through
> > other ebuild-files?
> >
> > Or should I omit defining sys-users with a fixed id given?
> 
> In principle packages should never depend on any fixed user id. They should 
> look at the passwd database for their uid. The only exception is root which 
> has a predefined userid.

Ack. But:

# find /usr/portage -name '*ebuild' | \
        xargs grep -h 'useradd .*-u'| sort -u | wc

counts 19 packages.

How can I prevent from grabbing a fixed uid of an another (not yet
installed) package when using the correct useradd (without -u) in my
ebuild?

Martin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Grant Goodyear]

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

> In principle packages should never depend on any fixed user id. They should 
> look at the passwd database for their uid. The only exception is root which 
> has a predefined userid.

I believe that Mr. Lesser is asking how one decides on uid/gid's for new
packages that should run as something other than root.  (For example,
apache runs as apache.apache, which maps to uid=81 and gid=81, and those
numbers are defined in the /etc/passwd file that's part of baselayout.)

Unfortunately, we don't have a good answer to that question just yet. 
The plan is to generate a table of already-taken uid/gid numbers 
(see
http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/eid_database/), but
there's clearly a lot of work that needs to be done yet.  My best
suggestion at the moment is to see what numbers debian is using for your
package, check to see if they conflict with anything we have (take a
look at the above "database" as well as the passwd and group files at
http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/rc-scripts/etc/),
and go from there.

Best,
g2boojum
-- 
Grant Goodyear <g2boojum@gentoo.org>

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

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Grant Goodyear]

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

On Fri, 2003-05-30 at 13:09, Vadim wrote:
> How about fixing the system? For example something like this:
> 
> useradd foo
> FOO_UID=`awk -F: '$1 == "foo" {printf $3}' /etc/passwd`
> FOO_GID=`awk -F: '$1 == "foo" {printf $4}' /etc/passwd`

Essentially that _is_ the plan.  We're working on it.

-g2boojum-
-- 
Grant Goodyear <g2boojum@gentoo.org>

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

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Martin Lesser]

Grant Goodyear <g2boojum@gentoo.org> writes:
> Paul de Vrieze <pauldv@gentoo.org> writes:
> > In principle packages should never depend on any fixed user id. They
> > should look at the passwd database for their uid. The only exception
> > is root which has a predefined userid.
> I believe that Mr. Lesser is asking how one decides on uid/gid's for
> new packages that should run as something other than root.

Exactly.

> Unfortunately, we don't have a good answer to that question just yet.
> The plan is to generate a table of already-taken uid/gid numbers
> ... My best suggestion at the moment is to see what numbers debian is
> using for your package, check to see if they conflict with anything we
> have (take a look at the above "database" as well as the passwd and
> group files at
> http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/rc-scripts/etc/),
> and go from there.

And there are the problems:

1. Several uid's/gid's differ from other distris (debian i.e. assigns
   31/32 for postgres, gentoo uses 70/70 for postgres but 31/31 for
   squid, so having both distris on different hosts leads to really
   'funny' results if you also use a central user repository or try to
   merge both passwd-files, see 3.)

   If you have a access to a running debian system look at
   /usr/share/base-passwd/passwd.master

2. In /etc/passwd from baselayout there are several users predefined
   which are really unnecessary on many systems. Why do I need a user
   games? Or squid on a host which never runs a proxy or another proxy
   like oops?  Etc.

3. If one runs openldap for authentification and nss one don't want to
   maintain two sources of uid/gid's which - if you run different
   distris - may conflict in an odd way.

IMO a clearer approach could be:

1. The predefined entries in /etc/passwd should be reduced to exactly 1
   entry for root, all other (system-)users could be created dynamicly
   by the ebuilds without assigning a fixed uid/gid.

2. The current ebuilds which assign _fixed_ uids/gids could be fixed so
   they don't use the appropriate useradd/groupadd options any longer.

I don't see any benefits of developing and/or maintaining a predefined
/etc/passwd with more than exactly one entry for root.

Just my 0.02$

Martin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2635 bytes --]

On Saturday 31 May 2003 10:53, Martin Lesser wrote:
>
> 1. Several uid's/gid's differ from other distris (debian i.e. assigns
>    31/32 for postgres, gentoo uses 70/70 for postgres but 31/31 for
>    squid, so having both distris on different hosts leads to really
>    'funny' results if you also use a central user repository or try to
>    merge both passwd-files, see 3.)
>
>    If you have a access to a running debian system look at
>    /usr/share/base-passwd/passwd.master

IMHO applications should not care about the actual uid's gid's they have, only 
that they can find theirs from the passwd database. Applications that need 
hard uids/gids should be patched. (Of course it should be possible to ensure 
the existence of a particular username /groupname before the configuration 
step. But that is possible in current portage.

>
> 2. In /etc/passwd from baselayout there are several users predefined
>    which are really unnecessary on many systems. Why do I need a user
>    games? Or squid on a host which never runs a proxy or another proxy
>    like oops?  Etc.
>
You are right, apps should request their own users/groups if needed.

> 3. If one runs openldap for authentification and nss one don't want to
>    maintain two sources of uid/gid's which - if you run different
>    distris - may conflict in an odd way.
>

Normally in such a setup it makes very much sense to have system users such as 
root and service users (for daemons) to be still in passwd, and have only 
real users (uid>1000 or whatever is defined) be served by the ldap database. 
This makes sure that the system is still working even if the ldap server is 
offline. (Also put at least one acount in passwd that allows ssh logins)

> IMO a clearer approach could be:
>
> 1. The predefined entries in /etc/passwd should be reduced to exactly 1
>    entry for root, all other (system-)users could be created dynamicly
>    by the ebuilds without assigning a fixed uid/gid.
>
Almost agreed, users like nobody and others are also required in baselayout, 
but the idea is ok.

> 2. The current ebuilds which assign _fixed_ uids/gids could be fixed so
>    they don't use the appropriate useradd/groupadd options any longer.

They should be indeed.

> I don't see any benefits of developing and/or maintaining a predefined
> /etc/passwd with more than exactly one entry for root.

Agreed except the need for a few more predefined users /groups (The users 
group is for example also required)

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Martin Lesser]

Paul de Vrieze <pauldv@gentoo.org> writes:

> On Saturday 31 May 2003 10:53, Martin Lesser wrote:
> > IMO a clearer approach could be:
> >
> > 1. The predefined entries in /etc/passwd should be reduced to exactly 1
> >    entry for root, all other (system-)users could be created dynamicly
> >    by the ebuilds without assigning a fixed uid/gid.
> Almost agreed, users like nobody and others are also required in
> baselayout, but the idea is ok.

You're right: users daemon, man etc. are required for a running system
but i.e. user man could also be checked/added by the ebuild for man or
man-pages. Almost every system-user could be added by the appropriate
ebuild so one gets a really 'clean' passwd where only the real used
users appear. Ok, one had to run etc-update more often when setting up
new services, but that's not bad at all.

> > 2. The current ebuilds which assign _fixed_ uids/gids could be fixed so
> >    they don't use the appropriate useradd/groupadd options any longer.
> They should be indeed.

I got a perhaps helpful list of 44 ebuilds where fixed uid's are used
with

# find /usr/portage -name '*ebuild' | \
        xargs grep 'useradd .*-u *[0-9]' | \
        sort -u | cut -f1 -d':' | cut -f4- -d'/'

Not sure whether this result is complete.

Should lintool also check the use of fixed uid's and report this as
error?

And coming back to my original question concerning nullmailer: I will
create my ebuild without a fixed uid/gid and hope that it will not
collide with any other ebuild used in future.

Martin


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[leon j. breedt]

On Sat, 31 May 2003 20:53, Martin Lesser wrote:
> I don't see any benefits of developing and/or maintaining a predefined
> /etc/passwd with more than exactly one entry for root.
agreed, for a source-based distribution its unnecessary. for a binary based 
distribution, some applications take numeric values at compile-time (qmail 
comes to mind). no reason they couldn't be patched, though...

if there's a table of allocated uids/gids for applications which absolutely 
need static ones, then there's no need to have this unnecessary crap 
cluttering up the default /etc/passwd, and Gentoo developers can push out 
creation of these into the package config part of an ebuild. 

leon


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Martin Lesser]

"leon j. breedt" <ljb@neverborn.ORG> writes:

> some applications take numeric values at compile-time (qmail comes to
> mind). no reason they couldn't be patched, though...

No need for patches. Checking|Creating the needed users in src_unpack()
or src_compile() with enewuser() would do it.

Martin

-- 
Express-Kommunikation mit Jabber:
JabberID: martin@jabber.bettercom.de
Infos unter http://www.better-com.de/pages/im.php

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Pascal Bourguignon]

Martin Lesser writes:
> Grant Goodyear <g2boojum@gentoo.org> writes:
> > Unfortunately, we don't have a good answer to that question just yet.
> > The plan is to generate a table of already-taken uid/gid numbers
> > ... My best suggestion at the moment is to see what numbers debian is
> > using for your package, check to see if they conflict with anything we
> > have (take a look at the above "database" as well as the passwd and
> > group files at
> > http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/rc-scripts/etc/),
> > and go from there.
> 
> 1. Several uid's/gid's differ from other distris (debian i.e. assigns
> 2. In /etc/passwd from baselayout there are several users predefined
> 3. If one runs openldap for authentification and nss one don't want to
> 1. The predefined entries in /etc/passwd should be reduced to exactly 1
> 2. The current ebuilds which assign _fixed_ uids/gids could be fixed so
>
> I don't see any benefits of developing and/or maintaining a predefined
> /etc/passwd with more than exactly one entry for root.

/etc/passwd and /etc/group must not be managed by UID/GID!

Each package may ask for a set  of user names and group names, and the
local system administrator can assign whatever UID/GID to these names.

Note  that  dependending  on  the  underliying system,  you  may  have
different  constraints  on  these  UID/GID.  Like  having  ID<100  for
auto-su-able or things like that.

For example, tar stores the names  of the owner and group of each file
in its archives.


-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[Evan Powers]

On Saturday 31 May 2003 04:53 am, Martin Lesser wrote:
> I don't see any benefits of developing and/or maintaining a predefined
> /etc/passwd with more than exactly one entry for root.

I'm quite tempted to agree with you, but one problem does come to mind. Unless 
I'm missing something, it's important enough to prevent such an approach.

Say any one of three things happens:
1) Your computer has problems and you want to move the drive onto a friend's 
system to repair it.
2) You loose / but not /usr, /var, whatever. You reinstall / but keep the 
other undamaged partitions.
3) You get hacked and have to replace /, but certain other filesystems contain 
only data and therefore are safe to keep

The common thread is that you want to mount a filesystem on a system with a 
/etc/passwd different from the one that filesystem was created under.

Unlike applications, the filesystem can't look at /etc/passwd for the UID/GID 
mappings. If the mappings on different machines aren't' the same, you can't 
easily move a drive to another machine and mount it.

If you emerge packages in a different order, the UID/GIDs in the new 
/etc/passwd will be dynamically generated differently, and won't match those 
in the old system. Changes in ebuild interdependencies would cause this to 
happen even if you issue the exact same sequence of emerge commands.

I can see it being a huge practical advantage to know that two installs will 
have the same UID/GID assignments, and therefore that disk drives can be 
moved between them without mismatches.

Evan


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Assigning unique system uid/gid for new ebuild

[George Shapovalov]

On Saturday 31 May 2003 16:43, Evan Powers wrote:
> On Saturday 31 May 2003 04:53 am, Martin Lesser wrote:
> > I don't see any benefits of developing and/or maintaining a predefined
> > /etc/passwd with more than exactly one entry for root.
> I can see it being a huge practical advantage to know that two installs
> will have the same UID/GID assignments, and therefore that disk drives can
> be moved between them without mismatches.

Well, to address that we can create a "master-list" of gentuid/gentgid's a-la 
/etc/services. When a package needs user/group it consults these lists in 
order to pick "proper" id.
But then is there any security implication in doing it this way or otherwise? 
If somehow security can be enhanced by keeping u/gids's random this may be 
made optional and even with option to randomize u/gid's more..

George



--
gentoo-dev@gentoo.org mailing list