[gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd

Discussion:

(too old to reply)

Dale

2024-04-11 01:30:01 UTC

Howdy,

This failed once before but I didn't worry about it. However, since the
profile update, it still fails. I'd like to figure out how to fix it.
I tried doing a emerge -C and then emerging it again. No help. This is
the output. It's not to long, whole thing. :-D

'/var/log/portage/acct-user:man-1-r3:20240411-011746.log'
Jobs: 0 of 1 complete, 1 failed Load avg: 2.12,

1.62, 1.72
* Package:    acct-user/man-1-r3:0
* Repository: gentoo
* Maintainer: base-***@gentoo.org
* USE:        abi_x86_64 amd64 elibc_glibc kernel_linux
* FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox

Unpacking source...
Source unpacked in /var/tmp/portage/acct-user/man-1-r3/work
Preparing source in /var/tmp/portage/acct-user/man-1-r3/work ...
Source prepared.
Configuring source in /var/tmp/portage/acct-user/man-1-r3/work ...
Source configured.
Compiling source in /var/tmp/portage/acct-user/man-1-r3/work ...
Source compiled.
Test phase [not enabled]: acct-user/man-1-r3
Install acct-user/man-1-r3 into

/var/tmp/portage/acct-user/man-1-r3/image

Completed installing acct-user/man-1-r3 into

/var/tmp/portage/acct-user/man-1-r3/image

* Final size of build directory: 0 KiB
* Final size of installed tree: 4 KiB

./
./usr/
./usr/lib/
./usr/lib/sysusers.d/
./usr/lib/sysusers.d/acct-user-man.conf

Done.

* checking 1 files for package collisions

Merging acct-user/man-1-r3 to /

error writing passwd entry: Invalid argument
* User man already exists
--- /usr/
--- /usr/lib/
--- /usr/lib/sysusers.d/

/usr/lib/sysusers.d/acct-user-man.conf

* Removing user man from group(s): root
* To retain the user's group membership in the local system
* config, override with ACCT_USER_MAN_GROUPS or
* ACCT_USER_MAN_GROUPS_ADD in make.conf.
* Documentation reference:
*
https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration#Override_user_groups
* Updating user man
usermod: user 'man' does not exist in /etc/passwd
usermod: failed to unlock /etc/gshadow
* usermod: user 'man' does not exist in /etc/passwd
* usermod: failed to unlock /etc/gshadow
* ERROR: acct-user/man-1-r3::gentoo failed (postinst phase):
*   usermod failed with status 6
*
* Call stack:
*     ebuild.sh, line 136: Called pkg_postinst
*   environment, line 884: Called acct-user_pkg_postinst
*   environment, line 417: Called die
* The specific snippet of code:
*               die "usermod failed with status ${status}";
*
* If you need support, post the output of `emerge --info
'=acct-user/man-1-r3::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=acct-user/man-1-r3::gentoo'`.
* The complete build log is located at
'/var/log/portage/acct-user:man-1-r3:20240411-011746.log'.
* For convenience, a symlink to the build log is located at
'/var/tmp/portage/acct-user/man-1-r3/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/acct-user/man-1-r3/temp/environment'.
* Working directory: '/var/tmp/portage/acct-user/man-1-r3/empty'
* S: '/var/tmp/portage/acct-user/man-1-r3/work'
* FAILED postinst: 1
*
* The following package has failed to build, install, or execute postinst:
*
* (acct-user/man-1-r3:0/0::gentoo, ebuild scheduled for merge), Log file:
*   '/var/log/portage/acct-user:man-1-r3:20240411-011746.log'
*

* GNU info directory index is up-to-date.
(chroot) ***@fireball / #

Any ideas? It did install once long ago when the group and user thing
started.

Ideas??

Dale

:-) :-)

J. Roeleveld

2024-04-11 05:30:01 UTC

Permalink

Post by Dale
Howdy,
This failed once before but I didn't worry about it. However, since the
profile update, it still fails. I'd like to figure out how to fix it.
I tried doing a emerge -C and then emerging it again. No help. This is
the output. It's not to long, whole thing. :-D

'/var/log/portage/acct-user:man-1-r3:20240411-011746.log'
Jobs: 0 of 1 complete, 1 failed Load avg: 2.12,

Post by Dale
* FAILED postinst: 1
*
*
* '/var/log/portage/acct-user:man-1-r3:20240411-011746.log'
*
* GNU info directory index is up-to-date.
Any ideas? It did install once long ago when the group and user thing
started.
Ideas??

First idea, if "man" exists, check if it matches current systems.

This is on a system less then 1 month old:

$ id man
uid=13(man) gid=15(man) groups=15(man)

--
Joost

Dale

2024-04-11 08:20:01 UTC

Permalink

Post by J. Roeleveld

'/var/log/portage/acct-user:man-1-r3:20240411-011746.log'
Jobs: 0 of 1 complete, 1 failed Load avg: 2.12,

First idea, if "man" exists, check if it matches current systems.
$ id man
uid=13(man) gid=15(man) groups=15(man)
--
Joost

Mine says:

***@fireball / # id man
uid=14357(man) gid=0(root) groups=0(root),15(man)
***@fireball / #

It doesn't match yours but it has something there. I'm surprised that
doing a emerge -C and then emerging it again didn't fix it but I guess
it adds something to those files but doesn't remove it when
uninstalled. So, I did some editing. The old line, I commented it
out. Then it emerged and added the new line.

man:x:13:15:System user; man:/dev/null:/sbin/nologin
#man:!:14357:0:99999:7:::

With it set like that, it emerges. This is what the output of your
command looks like now.

***@fireball / # id man
uid=13(man) gid=15(man) groups=15(man)
***@fireball / #

Now it matches yours.

Is this a bug or something? I don't tend to mess with that file
myself. :/

Dale

:-) :-)

J. Roeleveld

2024-04-11 09:00:01 UTC

Permalink

Post by Dale

Post by J. Roeleveld

'/var/log/portage/acct-user:man-1-r3:20240411-011746.log'
Jobs: 0 of 1 complete, 1 failed Load avg: 2.12,

First idea, if "man" exists, check if it matches current systems.
$ id man
uid=13(man) gid=15(man) groups=15(man)
--
Joost

uid=14357(man) gid=0(root) groups=0(root),15(man)
It doesn't match yours but it has something there. I'm surprised that
doing a emerge -C and then emerging it again didn't fix it but I guess
it adds something to those files but doesn't remove it when
uninstalled. So, I did some editing. The old line, I commented it
out. Then it emerged and added the new line.
man:x:13:15:System user; man:/dev/null:/sbin/nologin
With it set like that, it emerges. This is what the output of your
command looks like now.
uid=13(man) gid=15(man) groups=15(man)
Now it matches yours.
Is this a bug or something? I don't tend to mess with that file
myself. :/
Dale
:-) :-)

You might have some files owned by an unknown user on your system now
(especially man-pages?)

Looking back at the original error message, it did complain about "man" being
part of the "root" group.
doing a usermod to remove that group would have worked as well.

--
Joost

Michael

2024-04-11 08:00:01 UTC

Permalink

Completed installing acct-user/man-1-r3 into

/var/tmp/portage/acct-user/man-1-r3/image

OK, so far so good. :-)

Post by Dale
* Final size of build directory: 0 KiB
* Final size of installed tree: 4 KiB
./
./usr/
./usr/lib/
./usr/lib/sysusers.d/
./usr/lib/sysusers.d/acct-user-man.conf

Done.

* checking 1 files for package collisions

Merging acct-user/man-1-r3 to /

error writing passwd entry: Invalid argument
* User man already exists
--- /usr/
--- /usr/lib/
--- /usr/lib/sysusers.d/

/usr/lib/sysusers.d/acct-user-man.conf

* Removing user man from group(s): root

What?! Group 'root' should only have user 'root' as its member:

# grep root:x /etc/group
root:x:0:root

Post by Dale
* To retain the user's group membership in the local system
* config, override with ACCT_USER_MAN_GROUPS or
* ACCT_USER_MAN_GROUPS_ADD in make.conf.
*
https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration#Overri
de_user_groups * Updating user man
usermod: user 'man' does not exist in /etc/passwd

This is not right, unless you removed 'man' manually?

# grep man /etc/passwd
man:x:13:15:System user; man:/dev/null:/sbin/nologin

Post by Dale
usermod: failed to unlock /etc/gshadow
* usermod: user 'man' does not exist in /etc/passwd
* usermod: failed to unlock /etc/gshadow

# stat /etc/passwd
File: /etc/passwd
Size: 1636 Blocks: 4 IO Block: 4096 regular file
Device: 259,2 Inode: 18587 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)

# stat /etc/shadow
File: /etc/shadow
Size: 815 Blocks: 2 IO Block: 4096 regular file
Device: 259,2 Inode: 18602 Links: 1
Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)

# stat /etc/gshadow
File: /etc/gshadow
Size: 636 Blocks: 2 IO Block: 4096 regular file
Device: 259,2 Inode: 18562 Links: 1
Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root)

Check what yours look like, then try to correct them. It would be a good idea
to fsck the partition too and check smartctl, in case you have fs corruption.

Dale

2024-04-11 09:30:01 UTC

Permalink

Post by Michael

Completed installing acct-user/man-1-r3 into

/var/tmp/portage/acct-user/man-1-r3/image

OK, so far so good. :-)

Post by Dale
* Final size of build directory: 0 KiB
* Final size of installed tree: 4 KiB
./
./usr/
./usr/lib/
./usr/lib/sysusers.d/
./usr/lib/sysusers.d/acct-user-man.conf

Done.

* checking 1 files for package collisions

Merging acct-user/man-1-r3 to /

error writing passwd entry: Invalid argument
* User man already exists
--- /usr/
--- /usr/lib/
--- /usr/lib/sysusers.d/

/usr/lib/sysusers.d/acct-user-man.conf

* Removing user man from group(s): root

# grep root:x /etc/group
root:x:0:root

This is not right, unless you removed 'man' manually?
# grep man /etc/passwd
man:x:13:15:System user; man:/dev/null:/sbin/nologin

Post by Dale
usermod: failed to unlock /etc/gshadow
* usermod: user 'man' does not exist in /etc/passwd
* usermod: failed to unlock /etc/gshadow

# stat /etc/passwd
File: /etc/passwd
Size: 1636 Blocks: 4 IO Block: 4096 regular file
Device: 259,2 Inode: 18587 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
# stat /etc/shadow
File: /etc/shadow
Size: 815 Blocks: 2 IO Block: 4096 regular file
Device: 259,2 Inode: 18602 Links: 1
Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
# stat /etc/gshadow
File: /etc/gshadow
Size: 636 Blocks: 2 IO Block: 4096 regular file
Device: 259,2 Inode: 18562 Links: 1
Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root)
Check what yours look like, then try to correct them. It would be a good idea
to fsck the partition too and check smartctl, in case you have fs corruption.

I fixed it by commenting out the entry in the passwd file. It then
created a new entry. I guess it was set wrong at some point. Just
looks like emerge would be able to update it tho. Joost showing my
setting was different gave me the clue that my current entry was wrong.
I was kinda chicken to comment it out or remove it before then. ;-)

Dale

:-) :-)

Michael

2024-04-11 09:40:02 UTC

Permalink

It begs the question who/what could have changed the root group membership to
include the system account 'man'. This is highly irregular. Have you looked
at your backups to find out when /etc/group was changed last time? Also
emerge.log to find the last time acct-user/man was installed successfully
before this error started occurring.

Dale

2024-04-11 12:00:01 UTC

Permalink

Post by Michael

Well, this has been failing for a while. It's just that with the
profile change, I wanted to re-emerge all packages. I'm sure this one
hasn't really changed or anything but still, I wanted a clean start.

My OS backup updates each week. So, backups is far to up to date to
know. It's what I use to build the binary packages in. I also
sometimes experiment as well when some package is giving me grief. I
mostly just use the -k option on my main OS.

I looked in /usr/share/man, I guess that is where most if not all man
pages are, and they all appear to be owned by root and group is root.
Should they be owned by man? If possible, can you post the owner and
group for yours? I can change mine. I tested a few man pages, they all
post fine but I'm usually root anyway. Works for user dale to tho.

Thanks.

Dale

:-) :-)

Michael

2024-04-11 15:00:01 UTC

Permalink

Post by Michael

It begs the question who/what could have changed the root group membership
to include the system account 'man'. This is highly irregular. Have you
looked at your backups to find out when /etc/group was changed last time?
Also emerge.log to find the last time acct-user/man was installed
successfully before this error started occurring.

Well, this has been failing for a while. It's just that with the
profile change, I wanted to re-emerge all packages. I'm sure this one
hasn't really changed or anything but still, I wanted a clean start.
My OS backup updates each week. So, backups is far to up to date to
know. It's what I use to build the binary packages in. I also
sometimes experiment as well when some package is giving me grief. I
mostly just use the -k option on my main OS.
I looked in /usr/share/man, I guess that is where most if not all man
pages are, and they all appear to be owned by root and group is root.
Should they be owned by man? If possible, can you post the owner and
group for yours? I can change mine. I tested a few man pages, they all
post fine but I'm usually root anyway. Works for user dale to tho.
Thanks.
Dale
:-) :-)

The /usr/share/man directory and man pages within it are owned by root:root;
e.g.

# ls -al /usr/share/man/man8/agetty.8.bz2
-rw-r--r-- 1 root root 7307 Apr 4 10:46 /usr/share/man/man8/agetty.8.bz2

The problem in your case was the system account 'man' had been added to group
'root'. This creates a privilege escalation and as such it is suspicious.
Had you done this by accident and now you corrected it, then hopefully you do
not need to be unduly worried. Had someone else done this ... then this
should be setting off alarm bells.

Dale

2024-04-11 15:10:01 UTC

Permalink

Post by Michael

It begs the question who/what could have changed the root group membership
to include the system account 'man'. This is highly irregular. Have you
looked at your backups to find out when /etc/group was changed last time?
Also emerge.log to find the last time acct-user/man was installed
successfully before this error started occurring.

Well, this has been failing for a while. It's just that with the
profile change, I wanted to re-emerge all packages. I'm sure this one
hasn't really changed or anything but still, I wanted a clean start.
My OS backup updates each week. So, backups is far to up to date to
know. It's what I use to build the binary packages in. I also
sometimes experiment as well when some package is giving me grief. I
mostly just use the -k option on my main OS.
I looked in /usr/share/man, I guess that is where most if not all man
pages are, and they all appear to be owned by root and group is root.
Should they be owned by man? If possible, can you post the owner and
group for yours? I can change mine. I tested a few man pages, they all
post fine but I'm usually root anyway. Works for user dale to tho.
Thanks.
Dale
:-) :-)

The /usr/share/man directory and man pages within it are owned by root:root;
e.g.
# ls -al /usr/share/man/man8/agetty.8.bz2
-rw-r--r-- 1 root root 7307 Apr 4 10:46 /usr/share/man/man8/agetty.8.bz2
The problem in your case was the system account 'man' had been added to group
'root'. This creates a privilege escalation and as such it is suspicious.
Had you done this by accident and now you corrected it, then hopefully you do
not need to be unduly worried. Had someone else done this ... then this
should be setting off alarm bells.

I don't recall editing this file ever. From my understanding, commands
are used to manage that file. I can't say for sure but it's doubtful I
edited that file.

I can easily do a emerge -ek world if you think it would be wise to do
so. I guess that would reset ownership of files as it reinstalls.
Thoughts?

Thanks.

Dale

:-) :-)

Michael

2024-04-11 15:50:01 UTC

Permalink

I don't recall editing this file ever. From my understanding, commands
are used to manage that file. I can't say for sure but it's doubtful I
edited that file.
I can easily do a emerge -ek world if you think it would be wise to do
so. I guess that would reset ownership of files as it reinstalls.
Thoughts?
Thanks.
Dale
:-) :-)

I can't really advise what to do, it depends on your level of concern about
this discrepancy with the 'man' account. The question to mull over is what
could a rogue 'man' account have changed since your last full emerge @world?

If you upgraded your profile from 17.1 to 23.0 recently you would have re-
emerged @world, so all packages would have been reinstalled. If you run find
to print recently changed files since the profile upgrade, you'll have some
pointers for packages to emerge again. Or, with the 'man' account safely back
in its box you can change passwds/keys and re-emerge the whole @world once
more.

If you are totally worried to the point of not being able to trust your
system, then you'll need to reformat and start with a fresh stage3 download
and fresh sources. Do not blindly copy all your configuration files from the
backups, but diff them to make sure only changes you approve make it into the
new system. This can be a lot of work, which you may not be inclined to
embark on and could potentially be an overkill.

Dale

2024-04-12 14:40:02 UTC

Permalink

Post by Michael

I don't recall editing this file ever. From my understanding, commands
are used to manage that file. I can't say for sure but it's doubtful I
edited that file.
I can easily do a emerge -ek world if you think it would be wise to do
so. I guess that would reset ownership of files as it reinstalls.
Thoughts?
Thanks.
Dale
:-) :-)

I can't really advise what to do, it depends on your level of concern about
this discrepancy with the 'man' account. The question to mull over is what
If you upgraded your profile from 17.1 to 23.0 recently you would have re-
to print recently changed files since the profile upgrade, you'll have some
pointers for packages to emerge again. Or, with the 'man' account safely back
more.
If you are totally worried to the point of not being able to trust your
system, then you'll need to reformat and start with a fresh stage3 download
and fresh sources. Do not blindly copy all your configuration files from the
backups, but diff them to make sure only changes you approve make it into the
new system. This can be a lot of work, which you may not be inclined to
embark on and could potentially be an overkill.

I guess I'll see what it does moving forward. I have to admit tho, I
wonder how it got changed to begin with. Certainly odd. I wonder if I
typed something in my mistake?? Anyway, time will tell. I'm behind a
VPN and pretty good router so maybe that will be enough.

Thanks.

Dale

:-) :-)