Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 148225
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Michael Hanselmann (hansmi) (RETIRED) <hansmi@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Casey Allen Shobe <cshobe@seattleserver.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 148225 depends on: Show dependency tree
Bug 148225 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2006-09-19 10:51 0000
I emerge djbdns as a part of every system build I do.  The lines added to
/etc/passwd are incorrect for three reasons:

1.  They specify the login shell to be /usr/sbin/nologin.  This doesn't exist
on a Gentoo system.  This should be /bin/false instead

2.  They specify the home directory to be /nonexistent.  This means I have to
go rmdir /nonexistent after the build, and it should be /dev/null instead.

3.  I'm not very sure about this one but other packages seem to always use a
reserved uid for the users created - i.e. 89 for vpopmail, 70 for postgres,
etc.  Should this be the same for the djbdns users?

------- Comment #1 From Michael Hanselmann (hansmi) (RETIRED) 2006-09-29 16:29:24 0000 -------
(In reply to comment #0)
> 1.  They specify the login shell to be /usr/sbin/nologin.  This doesn't exist
> on a Gentoo system.  This should be /bin/false instead

This is handled by the enewuser() function in eutils.eclass. The djbdns ebuild
only specifies "-1", which means enewuser() should use a shell that prevents
logging in. Look at the code yourself.

> 2.  They specify the home directory to be /nonexistent.  This means I have to
> go rmdir /nonexistent after the build, and it should be /dev/null instead.

Fixed in the ebuild I'm working on. It'll become -r19.

> 3.  I'm not very sure about this one but other packages seem to always use a
> reserved uid for the users created - i.e. 89 for vpopmail, 70 for postgres,
> etc.  Should this be the same for the djbdns users?

Not really. enewuser() tries every UID from 101 to 999 for users without a
specific UID. Look at the code yourself, again.

------- Comment #2 From Casey Allen Shobe 2006-09-29 17:05:39 0000 -------
> Look at the code yourself.

I'm not a developer, I'm an end user.

Should I start a new bug for portage about the /usr/sbin/nologin issue?

Regarding the UIDs, I know that some packages pick one between 101 and 999,
while others (i.e. vpopmail) have a hardcoded UID.  The hardcoded ones are
preferable to me, just because I like to have consistancy across multiple
servers.  I had assumed, possibly incorrectly, that any package could reserve a
UID below 1000 for it's exclusive use in Gentoo.

------- Comment #3 From Michael Hanselmann (hansmi) (RETIRED) 2006-09-29 17:20:27 0000 -------
(In reply to comment #2)
> Should I start a new bug for portage about the /usr/sbin/nologin issue?

No. This is the code detecting the shell to use:

for shell in /sbin/nologin /usr/sbin/nologin /bin/false /usr/bin/false
/dev/null ; do
    [[ -x ${ROOT}${shell} ]] && break
done

So, if /sbin/nologin doesn't exist, but /usr/sbin/nologin does, it's used.

> Regarding the UIDs, I know that some packages pick one between 101 and 999,
> while others (i.e. vpopmail) have a hardcoded UID.  The hardcoded ones are
> preferable to me, just because I like to have consistancy across multiple
> servers.  I had assumed, possibly incorrectly, that any package could reserve a
> UID below 1000 for it's exclusive use in Gentoo.

It's preferred not to have static UIDs, because allocating them needs
management. However, you can create the user(s) in advance, with your own UIDs.
The already existing user with the correct name will be used, regardless of the
UID.

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug