Thanks for the reply. Yes, I set that earlier, and it still is enabled:
# getsebool ondemand_manage_user_home_dir ondemand_manage_user_home_dir --> on
Well if you’re using local HOME directories getting errors on accessing files in that local HOME directory ondemand_manage_user_home_dir is where I’d look. Also - what’s the policy you’ve provided there in that text file?
I don’t think what you posted is what we’re looking for but we would be looking for denials in audit.log. Seems like the messages we’d see would be around files and a much higher uid, but I don’t know that for sure.
@tdockendorf please advise.
Do you mean what are the contents of the text file I uploaded? That is the contents of file “my-utilsrb110.te” that came from the “ausearch” step in my message. (I had to append suffix “.txt” to select it for upload in my browser.) The contents are short enough that I will put them here.
module my-utilsrb110 1.0;
require {
type user_home_dir_t;
type home_root_t;
type user_home_t;
type ood_pun_t;
class dir { add_name create read write };
}
#============= ood_pun_t ==============
allow ood_pun_t home_root_t:dir read;
#!!!! This avc is allowed in the current policy
allow ood_pun_t user_home_dir_t:dir { add_name create read write };
allow ood_pun_t user_home_t:dir read;
Thank you yes, I downloaded it. My question wasn’t really what is it - I was able to download it - but why did you need to make/add it I guess is my question? What prompted you I suppose.
That said - our selinux are very community driven so if you’ve found something that we need or don’t have we’re happy to evaluate pull requests!
That was prompted by a message in /var/log/messages that I saw after I changed SELinux to Permissive mode. That is in my message above, but here it is again:
May 19 10:38:26 r1trlhpcood setroubleshoot[52775]: SELinux is preventing utils.rb:110 from read access on the directory dir.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that utils.rb:110 should be allowed read access on the dir directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'utils.rb:110' --raw | audit2allow -M my-utilsrb110#012# semodule -X 300 -i my-utilsrb110.pp#012
The boolean you have enabled only allows access to user_home_dir_t. I would not expect anything in unprivileged /home to have home_root_t unless that is just the context for /home. Can you look in audit.log for what denials are around user_home_t and home_root_t , the path of what was denied should be in the audit.log if you grep for those contexts.
Sometimes due to copy operations or other things, the contexts get messed up too so if you find that some paths in /home have incorrect contexts can run restorecon -v <path> or just run restorecon -Rv /home/ood for example to fix all contexts based on path under that location.
That is part of my confusion — I am not seeing messages in audit.log about trying to access /home/ood. I tried just now, and the most recent reference to /home is when I was in the home directory of my administrative account and used sudo to change to root so that I could look at audit.log:
type=USER_CMD msg=audit(1653063022.754:4287): pid=63131 uid=999115364 auid=999115364 ses=165 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/emsisson-mda" cmd=2F62696E2F7375202D exe="/usr/bin/sudo" terminal=pts/0 res=success'UID="emsisson-mda" AUID="emsisson-mda"
After that I connected to Open OnDemand, logged in as ood@localhost, went to Files → Home Directory, received the error message. However, in audit.log, no reference to /home appeared following my sudo command.
Just now I ran grep for user_home_t and home_root_t in audit.log, but the only messages were from yesterday before I ran semodule on the my-utilsrb110 change.
I ran restorecon -Rv /home/ood and it generated the following output:
Relabeled /home/ood/ondemand from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data/sys from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data/sys/dashboard from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data/sys/dashboard/batch_connect from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data/sys/dashboard/batch_connect/sys from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data/sys/dashboard/batch_connect/sys/bc_desktop from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data/sys/dashboard/batch_connect/db from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data/sys/myjobs from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/ondemand/data/sys/myjobs/production.sqlite3 from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/file_from_ood from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0 Relabeled /home/ood/created-using-ood.txt from system_u:object_r:user_home_dir_t:s0 to system_u:object_r:user_home_t:s0
I flushed the browser caches and logged into Open OnDemand again, but received the error message again.
The following line is in /var/log/ondemand-nginz/ood/error.log:
App 63690 output: [2022-05-20 11:36:02 -0500 ] ERROR "Permission denied @ rb_file_s_lstat - /home/ood/.mozilla"
I ran the following:
# ps -efZ | grep 63690 | grep -v grep system_u:system_r:ood_pun_t:s0 ood 63690 63211 5 11:35 ? 00:00:02 ruby /opt/rh/ondemand/root/usr/share/passenger/helper-scripts/rack-loader.rb
and the following:
# ls -lZd /home/ood /home/ood/.mozilla drwx------. 5 ood ood unconfined_u:object_r:user_home_dir_t:s0 202 May 19 14:15 /home/ood drwxr-xr-x. 4 ood ood unconfined_u:object_r:mozilla_home_t:s0 39 Apr 12 07:57 /home/ood/.mozilla
What else should I try?
If you do restorecon -nv /home/ood/.mozilla does it print anything? If not I’m going to guess mozilla_home_t is the expected context which is not allowed by OnDemand SELinux policies.
I’m not sure it makes sense for OnDemand to account for all possible contexts on local home directories, not even sure if such a list exists. If the end goal is to use NFS, that is much easier since everything on NFS mount has same context so very easy to allow the access, which OnDemand policies can handle.
For now if local home is just for testing, I’d recommend forcing the context to be what OnDemand expects.
find /home/ood -maxdepth 1 -mindepth 1 -type d -exec chcon -v user_home_dir_t {} \;
There are ways to make this persist if you want, good docs are here: 4.7. SELinux Contexts – Labeling Files Red Hat Enterprise Linux 7 | Red Hat Customer Portal
Command
# restorecon -nv /home/ood/.mozilla
did not change anything.
Command
# find /home/ood -maxdepth 1 -mindepth 1 -type d -exec chcon -v -t user_home_dir_t {} \;
does allow the directory contents to be displayed.
I will do more testing then work on configuring LDAP authentication and mounting NFS home directories.
Thanks for the help and have a good weekend.
Just in relation to this, I had gotten this fixed when I was using just the local /home/. However, now that I am mounting the a ZFS pool over NTFS, my users are experiencing this issue again. Its solved by logging in via SSH on the first try, and then logging in via CAS as an AD-authorized user.
However, if they do not do this, the following is reported:
~ Joe G.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.