Initially, nothing relevant is shown within /var/log/audit/audit.log however, if I disable SELinux via setenforce 0 then I can use the Files app without seeing this error. When I reactivate SELinux, this error returns.
First a word of warning. Local home directories almost never work with OnDemand since OnDemand will write files to user’s home that are expected to be accessible on compute nodes. The time when it works is if OnDemand is on the NFS server so the $HOME is local to OnDemand but served as NFS to compute.
That said, to address the SELinux issues first try this to see if the context on $HOME/.config is correct:
restorecon -R -n -v /home/dvi322/.config
If the command outputs anything, remove the -n flag to restore the correct contexts. OnDemand expects to be able to access things with user_home_dir_t when the ondemand_manage_user_home_dir is enabled.
If the contexts don’t change with restorecon the next step is to generate a custom SELinux policy. When dealing with the “dontaudit” denials, it gets really tricky. These are my recommended steps:
# Make sure system and OnDemand is relatively idle and not used
# Truncate audit log
# Disable dontaudit
# Do things in OnDemand that are blocked with SELinux
# Then turn dontaudit back on
# Now generate custom policy
cat /var/log/audit/audit.log | audit2allow -M ood
semodule -i ood.pp
There will likely be more denials besides the getattr if OnDemand is trying to do anything besides getattr on the ~/.config location. So might have to repeat the steps and gradually build up a more complete custom policy. Once you get things working with your custom policy, can share the contents of ood.te from the audit2allow command and we can try and integrate those changes into the OnDemand SELinux policy.
Also be aware that when you diable the “dontaudit” you will likely get a lot of noise in the custom policy you might have to clean up. Anything that doesn’t pertain to ood_pun_t is likely not related to OnDemand and just system noise.