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.

Bug 2088455

Summary: ssh/pam_motd unable to open file with var_run_t label
Product: Red Hat Enterprise Linux 8 Reporter: Iker Pedrosa <ipedrosa>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.6CC: lvrabec, mmalik, ssekidde, zpytela
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-23 10:31:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2014458    

Description Iker Pedrosa 2022-05-19 13:36:54 UTC
Description of problem:
When using ssh to access a system. If the welcome message for the system is located in newly created file /run/motd.d/, then the welcome message is not shown.

Version-Release number of selected component (if applicable):
selinux-policy-3.14.3-95.el8

Steps to Reproduce:
1- Create a file in "/run/motd.d/" and write a welcome message in it. Example: "Welcome to this system"
2- ssh into the machine and check that the previously defined welcome message is shown in the command line.

Actual results:
"Welcome to this system" should appear in the command line.


Expected results:
"Welcome to this system" message doesn't appear in the command line.


Additional info:
I moved an existing file from "/etc/test" to "/run/motd.d/test" and I created a new one directly in "/run/motd.d/" called "another_test".

$ ls -lZ /run/motd.d/
total 8
-rw-r--r--. 1 root root unconfined_u:object_r:var_run_t:s0 25 May 19 08:28 another_test
-rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0     27 May 19 08:25 test

The message included in the "test" file is shown while the one from "another_test" isn't shown. As you can see there's a difference in the SELinux labelling "var_run_t" != "etc_t".

Some useful strace information:
17888 08:29:39.569432 openat(AT_FDCWD, "/run/motd.d/another_test", O_RDONLY) = -1 EACCES (Permission denied) <0.000167>
17888 08:29:39.569737 openat(AT_FDCWD, "/run/motd.d/test", O_RDONLY) = 10</run/motd.d/test> <0.000076>
17888 08:29:39.570000 fstat(10</run/motd.d/test>, {st_dev=makedev(0, 0x18), st_ino=70781, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=27, st_atime=1652963356 /* 2022-05-19T08:29:16.002944324-0400 */, st_atime_nsec=2944324, st_mtime=1652963101 /* 2022-05-19T08:25:01.074944324-0400 */, st_mtime_nsec=74944324, st_ctime=1652963338 /* 2022-05-19T08:28:58.299944324-0400 */, st_ctime_nsec=299944324}) = 0 <0.000007>
17888 08:29:39.570064 read(10</run/motd.d/test>, "I'm writing the motd file.\n", 27) = 27 <0.000008>
17888 08:29:39.570107 close(10</run/motd.d/test>) = 0 <0.000007>

Comment 2 Zdenek Pytela 2022-05-19 17:07:01 UTC
Iker,

How is the /run/motd.d directory expected be created, from cli only?
In Fedora or RHEL 9 there actually is no special SELinux support, its creation is handled by /usr/lib/tmpfiles.d/setup.conf from setup rpm instead. It also means that running restorecon on /run/motd.d would work as a workaround.

Comment 3 Iker Pedrosa 2022-05-23 10:31:51 UTC
(In reply to Zdenek Pytela from comment #2)
> Iker,
> 
> How is the /run/motd.d directory expected be created, from cli only?

It should be created by PAM on installation, and now that I take a look at it PAM isn't doing that.

Thanks for catching this problem. I'm closing this bugzilla.