Bug 234014 - chown: ntpd: illegal user name -- after freebsd-update to 12.0
Summary: chown: ntpd: illegal user name -- after freebsd-update to 12.0
Status: Closed DUPLICATE of bug 232921
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-RELEASE
Hardware: i386 Any
: --- Affects Many People
Assignee: Kyle Evans
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-14 15:59 UTC by Eric van Gyzen
Modified: 2021-02-24 01:42 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric van Gyzen freebsd_committer 2018-12-14 15:59:38 UTC
I just updated an i386 machine (not amd64) from 11.2-RELEASE to 12.0-RELEASE using freebsd-update.  On boot, the console says:

chown: ntpd: illegal user name

Sure enough, the ntpd user was in /etc/*passwd but _not_ in /etc/*pwd.db.

# getent passwd ntpd
# grep ntp master.passwd 
ntpd:*:123:123::0:0:NTP Daemon:/var/db/ntp:/usr/sbin/nologin
# strings spwd.db  | grep ntp
# strings pwd.db | grep ntp

Also, ntpd is running as root.

The pwd db files were newer than the plain text files, so pwd_mkdb did run during the upgrade:

# stat -x master.passwd passwd spwd.db pwd.db 
  File: "master.passwd"
  Size: 3019         FileType: Regular File
  Mode: (0600/-rw-------)         Uid: (    0/    root)  Gid: (    0/   wheel)
Device: 0,70   Inode: 1036545    Links: 1
Access: Fri Dec 14 09:30:48 2018
Modify: Fri Dec 14 09:30:48 2018
Change: Fri Dec 14 09:32:39 2018
  File: "passwd"
  Size: 2509         FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (    0/    root)  Gid: (    0/   wheel)
Device: 0,70   Inode: 1036629    Links: 1
Access: Fri Dec 14 09:30:48 2018
Modify: Fri Dec 14 09:30:48 2018
Change: Fri Dec 14 09:32:39 2018
  File: "spwd.db"
  Size: 40960        FileType: Regular File
  Mode: (0600/-rw-------)         Uid: (    0/    root)  Gid: (    0/   wheel)
Device: 0,70   Inode: 1036680    Links: 1
Access: Fri Dec 14 09:48:57 2018
Modify: Fri Dec 14 09:30:50 2018
Change: Fri Dec 14 09:32:40 2018
  File: "pwd.db"
  Size: 40960        FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (    0/    root)  Gid: (    0/   wheel)
Device: 0,70   Inode: 1036668    Links: 1
Access: Fri Dec 14 09:48:38 2018
Modify: Fri Dec 14 09:30:49 2018
Change: Fri Dec 14 09:32:40 2018

I wonder if pwd_mkdb ran against the wrong/old master.passwd file?

Simply running pwd_mkdb worked around the problem.
Comment 1 Eric van Gyzen freebsd_committer 2018-12-14 16:05:07 UTC
I didn't have this problem on systems that I upgraded with installworld, so I imagine it's a problem in freebsd-update.
Comment 2 Michael Laß 2018-12-15 11:45:38 UTC
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232921
Comment 3 commit-hook freebsd_committer 2020-12-17 03:43:04 UTC
A commit references this bug:

Author: kevans
Date: Thu Dec 17 03:42:54 UTC 2020
New revision: 368713
URL: https://svnweb.freebsd.org/changeset/base/368713

Log:
  freebsd-update: unconditionally regenerate passwd/login.conf files

  The existing logic is nice in theory, but in practice freebsd-update will
  not preserve the timestamps on these files. When doing a major upgrade, e.g.
  from 12.1-RELEASE -> 12.2-RELEASE, pwd.mkdb et al. appear in the INDEX and
  we clobber the timestamp several times in the process of packaging up the
  existing system into /var/db/freebsd-update/files and extracting for
  comparisons. This leads to these files not getting regenerated when they're
  most likely to be needed.

  Measures could be taken to preserve timestamps, but it's unclear whether
  the complexity and overhead of doing so is really outweighed by the marginal
  benefit.

  I observed this issue when pkg subsequently failed to install a package that
  wanted to add a user, claiming that the user was removed in the process.
  bapt@ pointed to this pre-existing bug with freebsd-update as the cause.

  PR:		234014, 232921
  Reviewed by:	bapt, emaste
  MFC after:	1 week
  Differential Revision:	https://reviews.freebsd.org/D27635

Changes:
  head/usr.sbin/freebsd-update/freebsd-update.sh
Comment 4 Kyle Evans freebsd_committer 2020-12-17 03:47:56 UTC
Closing this as a duplicate of 232921 so that I only need to update the metadata in one place. :-)

*** This bug has been marked as a duplicate of bug 232921 ***
Comment 5 commit-hook freebsd_committer 2021-02-24 01:40:37 UTC
A commit in branch releng/11.4 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=2ca137b4306dea2dbe1db31c44102060caedb19a

commit 2ca137b4306dea2dbe1db31c44102060caedb19a
Author:     Kyle Evans <kevans@FreeBSD.org>
AuthorDate: 2020-12-17 03:42:54 +0000
Commit:     Mark Johnston <markj@FreeBSD.org>
CommitDate: 2021-02-24 01:34:51 +0000

    MFC freebsd-update: unconditionally regenerate passwd/login.conf files

    The existing logic is nice in theory, but in practice freebsd-update will
    not preserve the timestamps on these files. When doing a major upgrade, e.g.
    from 12.1-RELEASE -> 12.2-RELEASE, pwd.mkdb et al. appear in the INDEX and
    we clobber the timestamp several times in the process of packaging up the
    existing system into /var/db/freebsd-update/files and extracting for
    comparisons. This leads to these files not getting regenerated when they're
    most likely to be needed.

    Measures could be taken to preserve timestamps, but it's unclear whether
    the complexity and overhead of doing so is really outweighed by the marginal
    benefit.

    I observed this issue when pkg subsequently failed to install a package that
    wanted to add a user, claiming that the user was removed in the process.
    bapt@ pointed to this pre-existing bug with freebsd-update as the cause.

    PR:             234014, 232921
    Approved by:    so
    Security:       FreeBSD-EN-21:08.freebsd-update

    (cherry picked from commit ebebc41e4cfe44b8e8fd881badf2fa2c4be65aa4)
    (cherry picked from commit cd7da1deb581122c94c3735b78fafdd04ce77b67)

 usr.sbin/freebsd-update/freebsd-update.sh | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)
Comment 6 commit-hook freebsd_committer 2021-02-24 01:42:45 UTC
A commit in branch releng/12.2 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=df378912ebc2fe2603fcbcedf72af9d7b0e94db7

commit df378912ebc2fe2603fcbcedf72af9d7b0e94db7
Author:     Kyle Evans <kevans@FreeBSD.org>
AuthorDate: 2020-12-17 03:42:54 +0000
Commit:     Mark Johnston <markj@FreeBSD.org>
CommitDate: 2021-02-24 01:42:01 +0000

    MFC freebsd-update: unconditionally regenerate passwd/login.conf files

    The existing logic is nice in theory, but in practice freebsd-update will
    not preserve the timestamps on these files. When doing a major upgrade, e.g.
    from 12.1-RELEASE -> 12.2-RELEASE, pwd.mkdb et al. appear in the INDEX and
    we clobber the timestamp several times in the process of packaging up the
    existing system into /var/db/freebsd-update/files and extracting for
    comparisons. This leads to these files not getting regenerated when they're
    most likely to be needed.

    Measures could be taken to preserve timestamps, but it's unclear whether
    the complexity and overhead of doing so is really outweighed by the marginal
    benefit.

    I observed this issue when pkg subsequently failed to install a package that
    wanted to add a user, claiming that the user was removed in the process.
    bapt@ pointed to this pre-existing bug with freebsd-update as the cause.

    PR:             234014, 232921
    Approved by:    so
    Security:       FreeBSD-EN-21:08.freebsd-update

    (cherry picked from commit ebebc41e4cfe44b8e8fd881badf2fa2c4be65aa4)
    (cherry picked from commit 5cf1ba21eebaf89cf4d8639a18345dc49116d1d5)

 usr.sbin/freebsd-update/freebsd-update.sh | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)