Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 2068 - apache installs as uid 1000 - potential clash with real users
Summary: apache installs as uid 1000 - potential clash with real users
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Donny Davies (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-24 10:18 UTC by Todd Wright
Modified: 2003-02-04 19:42 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Todd Wright 2002-04-24 10:18:42 UTC
When apache is emerged the following is added to /etc/passwd (not sure at this 
stage, where/what adds it - I assume its in the ebuild)

apache:x:1000:407:apache:/home/httpd:/bin/false

According to the 'adduser' man page: "Values between 0 and 99 are typically 
reserved for system accounts."  I believe application software such as apache 
that requires an id should use an id greater than 100, however there needs to 
be an upper limit as to what the applications are allowed to use, so that the 
admin has a basis from which to add real users.

I have been very generous on my other systems to date and allowed applications 
to use ids from 100 - 999, however uid 1000 clashes with the first 'real' user 
on my system.

If choosing 1000 for the first real user is not safe under gentoo, then what is 
the lowest uid that can be used for the first real user so that future 
automated additions to /etc/passwd do not clash?

Gentoo users (sysadmins) need to know what id's they can safely use for real 
users. If Gentoo is going to use any and all id's then there are going to be 
security problems.
Comment 1 Daniel Robbins (RETIRED) gentoo-dev 2002-04-24 11:09:00 UTC
Donny, I don't know the best solution for this one.  It would be nice if adduser
had an option to use a UID less than 99, but it doesn't seem to.
Comment 2 Todd Wright 2002-04-24 11:26:21 UTC
You have missunderstood the problem. This is not about adduser, and I believe 
adduser to be correct in its operation. (at least according to its 
documentation) 

The problem is that Apache is added to /etc/passwd as uid 1000, however I 
believe that uid 1000 and above should be reserved for real users with software 
applications being added with uid's no higher than 999

When I asked "what is the lowest uid that can be used for the first real user?" 
What I really meant was what is the highest uid Gentoo will ever allocate to 
system/application users so that I can safely use uids above that in order to 
avoid uid clashes?

I guess its really up to the ebuild maintainers whena dding entries 
to /etc/passwd to keep the uid of their application below a certain cuttoff. 
I'd like to know what that cuttoff is.

Does that make more sense, or have I confused the issue more?
Comment 3 Donny Davies (RETIRED) gentoo-dev 2002-04-24 16:09:54 UTC
okay, lets see..

adduser is called in apache's pkg_setup() function.  if there is not
an existing apache user/group, they will be created.

but adduser will not make a duplicate userid, will it?  i dont think
so anyway!  if you keep calling adduser from the command line, will
it not make incrementing, unique userids?

i agree userids > 1000 should be reserved specifically for the admin,
and its probably a bad idea for ebuilds to make them in that range.
im wondering exactly what security problems are _really_ involved
here, assuming that in fact useradd *does* create unique ids.
(i would bet money that it will *not* create duplicate userids)

either way, i suppose we should add an apache user/group to baselayout
immediately, to simpify the situation.  

whaddaya think?
Comment 4 Todd Wright 2002-04-25 03:34:38 UTC
Sorry, when I wrote the above I had not yet looked at the apache ebuild. 
(pressed for time) I have done so now and understand the focus on useradd. (I 
had assumed 'cat ... >>/etc/passwd'

My appologies, the misunderstanding was mine.

Useradd will not create a duplicate uid - it simply refuses with "user exists". 
You can try it out: useradd -u 999 blah (do this a few times)

I realised based on the above, that if you're considering adding it to the 
baselayout, then it would be coded with a static pre-defined uid. If a uid is 
pre-selected, you could simply add -u xxx to the useradd call in the apache 
ebuild with the chosen uid, and provided it doesnt already exist, useradd will 
happily add it. This is probably the simplest solution as things currently 
stand.

Whehter it ends up in the baselayout or not is the call of the Gentoo team. Its 
probably a bit of a trade off. On one hand, distributions such as Suse 
predefine all of the 'application' userid's in the baselayout, which 
causes /etc/passwd to be full of userids that are never used (unless you 
install every optional package). This can be a little annoying.

With Gentoo being how it is, the above solution (adding -u xxx to hte ebuild) 
would at least limit /etc/passwd to only the applications that have been 
installed, but would require a central uid regsiter so that uids werent 
duplicatied by different ebuild contributors. 

On the other hand, placing these users in the baselayout requires no central 
register (the passwd file becomes the register).

Your call I guess.
Comment 5 Arcady Genkin (RETIRED) gentoo-dev 2002-04-26 04:20:08 UTC
Gentoo's /etc/passwd has user 'www' with UID 30.  What's it for?  IMO we could
use that user for apache's user.
Comment 6 Donny Davies (RETIRED) gentoo-dev 2002-04-26 11:14:21 UTC
too late, ive added user/group apache with userid/groupid 81 to baselayout.  
i've updated apache ebuild to suit as well.

all done, now everybody can be happy :)
Comment 7 Arcady Genkin (RETIRED) gentoo-dev 2002-04-26 13:38:12 UTC
Okay, but what is the user 'www' for, then?
Comment 8 Daniel Robbins (RETIRED) gentoo-dev 2002-05-07 11:55:43 UTC
Arcady: www is for this purpose.  not sure why woodchip did what he did.