Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
We've had a number of cases in the ceph test rig where we get some AVC denials when starting up the server. The bug is being tracked here:
http://tracker.ceph.com/issues/16397
...and here is one of the AVC denials:
avc: denied { add_name } for pid=22038 comm="rpc.mountd" name="channel" scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:sysctl_rpc_t:s0 tclass=dir permissive=1'
I think that the reason we see this rhel7 uses fopen() to open the channel files, which adds an implicit O_CREAT. Upstream switched to normal open() calls with the alternate libc compatibility rework.
In any case, I think that mountd somehow ends up racing with the kernel creating the proc files and so we end up trying to do an O_CREAT open here.
I think this is harmless. The kernel just does the upcall again later if it can't get the info here. But, we end up with these AVC denials in the logs and their automated test result scraping scripts get upset. Sigh...
What I'm not sure of is why we end up racing at all. It seems like the files ought to be created, but maybe some of the new parallel init stuff in systemd is allowing mountd to attempt to open these files before they've been created?
In any case, a trivial fix I think would be to simply have the selinux policy allow creates in /proc/net/rpc/*. That should be harmless since the kernel will prevent it from occurring.
Alternately, we could consider taking the alternate libc rework patches into rhel7's nfs-utils, which would fix it in another way.
(In reply to Jeff Layton from comment #0)
>
> Alternately, we could consider taking the alternate libc rework patches into
> rhel7's nfs-utils, which would fix it in another way.
What patches are you referring to...
Patch 510465f44669be366fdb59f40372a9c6123a0231, in particular, but there were some others merged around that time as well. IIRC, they were intended to allow nfs-utils to build against musl libc?
(In reply to Jeff Layton from comment #2)
> Patch 510465f44669be366fdb59f40372a9c6123a0231, in particular, but there
> were some others merged around that time as well. IIRC, they were intended
> to allow nfs-utils to build against musl libc?
Will that commit cherry-pick cleanly on the latest 7.4 so
it appears there is no dependencies...
Thanks for merging those patches. We've deployed the latest nfs-utils brew build into the ceph infrastructure and should hopefully be able to declare victory (or loss) in another week or two.
(In reply to Jeff Layton from comment #5)
> So far so good. I think we can declare success with
> nfs-utils-1.3.0-0.35.el7.x86_64.
Thanks Jeff help to verify this issue.
We'll do regression tests then.
(In reply to Yongcheng Yang from comment #7)
> (In reply to Jeff Layton from comment #5)
> > So far so good. I think we can declare success with
> > nfs-utils-1.3.0-0.35.el7.x86_64.
>
> Thanks Jeff help to verify this issue.
>
> We'll do regression tests then.
No regression issue is found till now.
Moving to VERIFIED as "SanityOnly".
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2017:2233
We've had a number of cases in the ceph test rig where we get some AVC denials when starting up the server. The bug is being tracked here: http://tracker.ceph.com/issues/16397 ...and here is one of the AVC denials: avc: denied { add_name } for pid=22038 comm="rpc.mountd" name="channel" scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:sysctl_rpc_t:s0 tclass=dir permissive=1' I think that the reason we see this rhel7 uses fopen() to open the channel files, which adds an implicit O_CREAT. Upstream switched to normal open() calls with the alternate libc compatibility rework. In any case, I think that mountd somehow ends up racing with the kernel creating the proc files and so we end up trying to do an O_CREAT open here. I think this is harmless. The kernel just does the upcall again later if it can't get the info here. But, we end up with these AVC denials in the logs and their automated test result scraping scripts get upset. Sigh... What I'm not sure of is why we end up racing at all. It seems like the files ought to be created, but maybe some of the new parallel init stuff in systemd is allowing mountd to attempt to open these files before they've been created? In any case, a trivial fix I think would be to simply have the selinux policy allow creates in /proc/net/rpc/*. That should be harmless since the kernel will prevent it from occurring. Alternately, we could consider taking the alternate libc rework patches into rhel7's nfs-utils, which would fix it in another way.