New users and groups

[gerard@…]

users:

root:x:0:0
nobody:x:65534:65534

groups:

root:x:0
console:x:1
tty:x:2
kmem:x:3
disk:x:4
utmp:x:5
nogroup:x:65534

[gerard@…]

Update fstab as well:

usbfs /proc/bus/usb usbfs devgid=14,devmode=0660 0 0

This option will only work if “Support for Host-side USB” and “USB device filesystem” are compiled into the kernel (not as a module).

Add a note here to create a usb group or alternate suggestions. For instance, the "root" group could possible be used as long as people understand the implications of such a thing. Might compromise security or not.

[gerard@…]

Note from Kevin regarding usbfs:

That would be my suggestion, most people don't need usbfs at all (I've never used it once), so it would seem to be more appropriate to be in the BLFS book in the section that installs scanning related software.

URL for this specific thread: ​http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-February/050610.html

[archaic@…]

Matt, are we going to move on this or is it relegated to a later release?

[Matthew Burgess]

Well, it certainly won't make 6.1. We'll need to see if/when BLFS are ready, so we can coordinate efforts.

[manuel@…]

IMHO BLFS is almost ready now: blfs/view/svn/postlfs/users.html

[archaic@…]

(In reply to comment #0)

users:

root:x:0:0 nobody:x:65534:65534

There doesn't seem to be a valid reason for using 65534 anymore. I suggest we strive to match BLFS which has already solved greater uid/gid issues than LFS will even encounter.

groups:

root:x:0 console:x:1

BLFS uses bin for gid 1. Since the next gid assigned by BLFS is 14, we have plenty of breathing room. I suggest either moving console after utmp, or just incrementing console to utmp by one number. Nothing dictates that we need a gid 1 in a base system.

nogroup:x:65534

Same argument as user nobody.

[Matthew Burgess]

OK, let's leave gid 1 free for BLFS' bin group, as long as we document why we're doing it, of course. Just shift console-utmp up one gid. Let's match BLFS' nobody and nogroup IDs too.

Thanks,

Matt.

[Jeremy Huntwork]

What's the status of this one? Are we aiming to implement this or 6.2 or is this an unknown future version?

[Jeremy Huntwork]

This ticket is marked as high, but no one seems to be touching it. For that matter, is there anything left to be done here? The bin gid is currently the same in LFS and BLFS as are the nobody uid and nogroup gid.

The only other thing I would possibly suggest, is to add from the start a dummy user for use in various testsuites throughout chapter 6. This would help with ticket #1877. We would only have to add a command at the end to remove the user (if desired).

[bdubbs@…]

I've been in favor of closing this for quite some time. There have been a couple of threads about it on the lists.

I think the hesitation in closing this is because Gerard created the ticket. From the BLFS point of view, a couple of the groups could be removed because they are not used by any {,B}LFS applications. For example: kmem, tape, daemon, floppy, disk, dialout, utmp.

OTOH leaving what we have doesn't hurt anything.

[Matthew Burgess]

Just to keep this one going for a bit longer...:-)

root:/sources/blfs/dbus-1.0.1# groupadd -g 18 messagebus &&

useradd -c "D-BUS Message Daemon User" -d /dev/null \

-u 18 -g messagebus -s /bin/false messagebus

useradd: unknown GID 1000 Group 'mail' not found. Creating the user mailbox file with 0600 mode.

So, adding:

mail:x:34

would seem sensible here, wouldn't it?

With regard to the 'unknown GID 1000' error, I even get this with `useradd --help'!

[Jeremy Huntwork]

I've seen that 'unknown GID 1000' error myself and it screams of something broken. At first glance/guess, it seems like something leftover from the tests for chapter 6 Coreutils. Recall that we set up a dummy user there with uid of 1000 and run tests as that user. Could shadow be picking that up somehow?

[Luca]

Replying to jhuntwork@linuxfromscratch.org:

I've seen that 'unknown GID 1000' error myself and it screams of something broken. At first glance/guess, it seems like something leftover from the tests for chapter 6 Coreutils. Recall that we set up a dummy user there with uid of 1000 and run tests as that user. Could shadow be picking that up somehow?

As already discussed, I've got some mails #1032 (New users and groups), it's a shadow problem.

From tarball of shadow-4.0.17; subdir etc; file useradd: #useradd defaults file GROUP=1000 HOME=/home/users INACTIVE=-1 EXPIRE= SHELL=/bin/bash SKEL=/etc/skel CREATE_MAIL_SPOOL=yes

For Shadow-4.0.18.1 it's the same; I tried removing users:x:100: from groups and the problem re-appeared; I've also modified /etc/default/useradd in this way: # useradd defaults file GROUP=100 HOME=/home INACTIVE=-1 EXPIRE= SHELL= SKEL=/etc/skel

I think the group users should be added to the /etc/group in Chapter 6.6 Creating Essential Files and Symlinks.

[Matthew Burgess]

I'm closing this now. It looks as if everything has been covered apart from the bash testsuite issue and the shadow problems. #1877 covers the bash issue, so it's not going to get lost. The Shadow problems are well understood (see ​http://linuxfromscratch.org/pipermail/lfs-dev/2007-March/059058.html) and will be fixed at the same time we upgrade to Shadow-4.0.18.1 (#1850).

[Jeremy Huntwork]

Milestone 6.3 deleted