Bug 1970644 - Error in <unknown> scriptlet in rpm package container-selinux
Summary: Error in <unknown> scriptlet in rpm package container-selinux
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: container-selinux
Version: 33
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-10 21:53 UTC by Chris Evich
Modified: 2021-11-30 19:14 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-30 19:14:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Chris Evich 2021-06-10 21:53:33 UTC
Description of problem:

When upgrading the package on a newly installed system, never having run any containers, upgrade scriptlet failure occurs.  It doesn't affect subsequent running of containers, but may cause intended labling changes to fail if there are multiple user home directories.

Version-Release number of selected component (if applicable):
container-selinux-2:2.162.2-2.fc33.noarch

How reproducible:
100%

Steps to Reproduce:
1. Install podman and container-selinux-2:2.160.2-1.fc33.noarch
2. Upgrade to container-selinux-2:2.162.2-2.fc33.noarch

Actual results:

```
[root@localhost ~]# dnf upgrade ...big list of download URLs...
...cut...
  Running scriptlet: container-selinux-2:2.162.2-2.fc33.noarch                    4/8
  Upgrading        : container-selinux-2:2.162.2-2.fc33.noarch                    4/8
  Running scriptlet: container-selinux-2:2.162.2-2.fc33.noarch                    4/8
Deprecated, use selabel_lookup

  Cleanup          : container-selinux-2:2.160.2-1.fc33.noarch                    5/8
  Running scriptlet: container-selinux-2:2.160.2-1.fc33.noarch                    5/8
Fixing Rootless SELinux labels in homedir
warning: %triggerpostun(container-selinux-2:2.162.2-2.fc33.noarch) scriptlet failed, exit status 255

Error in <unknown> scriptlet in rpm package container-selinux
```


Expected results:

No errors

Additional info:

First discovered in https://bodhi.fedoraproject.org/updates/FEDORA-2021-0c53d8738d

Comment 1 Daniel Walsh 2021-06-11 12:43:08 UTC
This can probably be ignored, but I would love to know why it failed?  Does this system have any homedirs?  Any users?

Comment 2 Chris Evich 2021-06-11 13:17:17 UTC
One user, one homedir.

My main concern (not knowing how the scriptlet works) is if there are 50 local users, the scriptlet fails after the 3rd one, will it still process the remaining 47?

Comment 3 Daniel Walsh 2021-06-11 13:31:05 UTC
This is what the scriptlet is doing.

    echo "Fixing Rootless SELinux labels in homedir"
    %{_sbindir}/restorecon -R /home/*/.local/share/containers/storage/overlay*  2> /dev/null

BTW For f33 this is probably not needed unless a really new kernel gets back ported to it.

Comment 4 Daniel Walsh 2021-06-12 10:36:13 UTC
Can you run this command on the host to see if it shows an error?  I guess we could add a

    %{_sbindir}/restorecon -R /home/*/.local/share/containers/storage/overlay*  2> /dev/null || true

To basically ignore errors.

Comment 5 Chris Evich 2021-06-14 21:11:41 UTC
Thanks, that's enough information to poke around some more.  Assuming this is bash or similar, I believe it enumerates the wild-card paths _before_ calling the command with them as parameters.  So ignoring the error might be bad - the restorecon won't run at all, and the reason why is hidden.  But I'm a bit fuzzy on this area of shell operations, I'll need to play with it to be sure...

Comment 6 Chris Evich 2021-06-14 21:20:59 UTC
...update: Bash seems to try and expand some wildcards, passing the rest into to the command.  In the case of non-existent files/directories, they're left up to the command to handle them internally.  So for this specific failure, it's the `restorecon` behavior with bad files that's important.  In other words, does it just throw an error but keep changing things, or does it completely give up at the first problem?

Comment 7 Daniel Walsh 2021-06-14 21:25:34 UTC
I have no idea.

Comment 8 Chris Evich 2021-06-14 21:28:43 UTC
Idea: Perhaps using the find command would be more reliable here.  Something like (untested) `find /home -path '*/.local/share/containers/storage/overlay*' -execdir %{_sbindir}/restorecon -R '{}' +`

Comment 9 Chris Evich 2021-06-14 21:30:07 UTC
It's fine, I'm just spit-balling.  I'll grab a VM and play with it more tomorrow, now that I know more what's under the covers.

Comment 10 Chris Evich 2021-06-15 15:07:11 UTC
Well crud...I'm unable to reproduce any errors at all running the 'restorecon' command manually.  I even tried doing some "evil things" like making a '/home/user/.local/share/containers/storage' file (normally it's a directory) then setting it immutable (chattr +i).  The only case where it fails is if _NO_ home directories contain container storage:

# restorecon -R /home/*/.local/share/containers/storage/overlay*
restorecon: SELinux: Could not get canonical path for /home/*/.local/share/containers/storage/overlay* restorecon: No such file or directory.

So, I'm confident that the error is harmless.  I'll play around with my find command idea, maybe it can be used instead of just ignoring _ALL_ errors (since some may be helpful/useful)...

Comment 11 Chris Evich 2021-06-15 16:44:52 UTC
...okay all done playing.  This seems to work well in my (manual) testing of the (equivalent) command:

%{_bindir}/find /home -maxdepth 6 -type d -path '*/.local/share/containers/storage/overlay*' -exec %{_sbindir}/restorecon -i -R '{}' +

I tested F34 with 7 home directories, with both no '.local/share/containers/storage' anywhere, and then with one of the users having done a 'podman run...' command.  In all cases 'restorecon' is called with the minimal number of directories to fix (recursively) - including zero.  No non-zero exit codes are returned in any case tested.

Note: There are some corner-cases where this conversion will fall short.  For example, on systems that have some/all users outside of /home or are using autofs (for example).  Similarly, it will probably throw a hissy-fit if /home is an NFS or SMB mount (for example).  It's also going to silently break if any user has $XDG_DATA_HOME set (for example in .bashrc) and pointing elsewhere.  I can't think of any uncomplicated workarounds/fixes for any of those.

This may cause non-trivial problems for support to diagnose for RHEL customers.  Perhaps it would be a nice favor if we helped support craft a KB article on this?  Does podman/buildah throw an error or would there be an AVC denial if some directory isn't labeled correctly?

Comment 12 Ed Santiago 2021-06-15 16:54:18 UTC
`find /home` makes me a little queasy: it can hang catastrophically over NFS, and doesn't account for home directories outside of `/home` nor for users with a nonstandard graphRoot. In my email of May 17 I suggested:

   awk -F: -v cstorage=/.local/share/containers/storage '$7 !~ /nologin/ {if (system("test -d " $6 cstorage)==0) {print $6 cstorage}}' </etc/passwd

...but I don't like that either (it, too, ignores nonstandard graphRoot).

Honestly, I think the least-worst solution is to `2>/dev/null` in the restorecon.

Comment 13 Chris Evich 2021-06-15 17:08:49 UTC
> the least-worst solution is to `2>/dev/null` in the restorecon.

That's what we do today - it both doesn't fix the problem, and it hides the cause.  See bug description.

A proper "stick head in sand" fix would be more like Dan's idea:

restorecon ... 2> /dev/null || true

We can address all the corner cases with a simple KB article including the typical error/AVC message.

Comment 14 Chris Evich 2021-07-16 15:48:31 UTC
Tested, this works: %{_sbindir}/restorecon -R /home/*/.local/share/containers/storage/overlay* &> /dev/null || true

Comment 15 Fedora Update System 2021-09-27 14:30:43 UTC
FEDORA-2021-143ad819a6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-143ad819a6

Comment 16 Fedora Admin user for bugzilla script actions 2021-10-16 00:14:12 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 17 Ben Cotton 2021-11-04 13:39:49 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 Ben Cotton 2021-11-04 14:09:22 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Ben Cotton 2021-11-04 15:06:25 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 20 Ben Cotton 2021-11-30 19:14:34 UTC
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.