Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-118365

RPM enforces having a local user/group

Linking RHIVOS CVEs to...Migration: Automation ...SWIFT: POC ConversionSync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • rhel-10.0
    • rpm
    • Yes
    • Important
    • rhel-swm
    • 0
    • False
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • Unspecified
    • Unspecified
    • Unspecified
    • None

      What were you trying to do that didn't work?

      A customer is building a custom package having files configured with S_ISUID/S_ISGID bits.
      When rpmfilesStat() executes, the following warning is seen:

      group XXX does not exist - using root
      

      This is because the customer is also having his user and group in a AD backend, not as local user/group.
      It appears that code changed with RHEL10 compared to RHEL9:
      RHEL10 code only checks for the group in /etc/group (and user in /etc/passwd) while until RHEL9 included, NSS functions were used, e.g.:

       65 int rpmugGid(const char * thisGname, gid_t * gid)
       66 {
       :
       92         grent = getgrnam(thisGname);
       :
      

      vs RHEL10:

      186 int rpmugGid(const char * thisGname, gid_t * gid)
      187 {
       :
      197         if (lookup_num(grpfile(), thisGname, 0, 2, &id))
      198             return -1;
       :
      
       41 static const char *grpfile(void)
       42 {
       43     return getpath("group", "/etc/group", &rpmug->grppath);
       44 }
      

      This is new and due to commit below:

      commit f3eaeeb7341085e1850e914350cf1f33d538320d
      Author: Panu Matilainen <pmatilai@redhat.com>
      Date:   Thu May 4 11:10:12 2023 +0300
      
          Make user/group info reliable operation across chroot
          
          There's no telling what sort of caching getpwnam() and friends perform
          behind the scenes, and worse, there's no way to explicitly reset those
          caches. This can lead to chrooted operations using user/group data from
          the host, which is simply wrong.
          
          Do our own parsing of /etc/passwd and /etc/group to fix. Besides the
          chroot matter, we then only ever lookup local system users and groups
          and not something from eg network name services. We cannot reliably
          do NSS in a chroot because doing so would require relying on binaries
          in the chroot, which in itself is completely unreliable. NSS is also
          unreliable in various rescue mode situations. Bottom line, local files
          are the only ones that can be guaranteed for rpm operation, and this
          change basically enforces that.
          
          Technically we should track chroot status for each lookup and flush the
          cache if the state changed, but this is an internal API and rpm usages
          only ever call it from one side of the chroot for a given operation.
          
          Fixes: #882, #1789
      

      I understand that there was an issue with chroots, but in normal conditions it seems overkill to me: many customers make use of remote users and groups, and, even if having non-local users and groups for services is not recommended, it's still supported.

      What is the impact of this issue to you?

      Customer cannot install his custom package properly.

      Please provide the package NVR for which the bug is seen:

      rpm-4.19.1.1-12.el10

      How reproducible is this bug?:

      Always

      Steps to reproduce

      1. Create a package with a non-local user and group for some file

      Expected results

      Installing goes fine

      Actual results

      File gets "root:root" ownership

              packaging-team-maint packaging-team-maint
              rhn-support-rmetrich Renaud Métrich
              Julio Entrena Perez, Renaud Métrich
              packaging-team-maint packaging-team-maint
              Software Management QE Software Management QE
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: