Bug 2167166

Summary:	fixfiles leave some unchange, is this correct?
Product:	[Fedora] Fedora	Reporter:	Mars <csiterallat>
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	37	CC:	dwalsh, lvrabec, mmalik, omosnacek, pkoncity, vmojzis, zpytela
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-06-27 19:00:08 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:

Description Mars 2023-02-05 11:04:28 UTC

#Description of problem:

Hello! I dont know is this a bug or not. I have some question please:
Thanks for answers.
Please do not blame me because Im using nvidia

1. Why not fix all file the `fixfiles -F onboot && reboot` command?
2. Is this ok? `Warning no default label for /dev/mqueue`
3. /run/user/* and /run/Network-Manager/ context ok? (Im using built in wireguard vpn) 
4. Why and how can go wrong SELinux contexts? Why would relabel?


## I run following command as root:

fixfiles -F onboot && reboot

## After reboot, I run:

fixfiles verify

I see following output:

Verifying / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /run /run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug /sys/kernel/tracing /tmp
Would relabel /dev/nvidia-uvm-tools from system_u:object_r:device_t:s0 to system_u:object_r:xserver_misc_device_t:s0
/dev/tty2 not reset as customized by admin to unconfined_u:object_r:user_tty_device_t:s0
Warning no default label for /dev/mqueue
Would relabel /run/NetworkManager/no-stub-resolv.conf from system_u:object_r:NetworkManager_var_run_t:s0 to system_u:object_r:net_conf_t:s0
Would relabel /run/user/1000/keyring from unconfined_u:object_r:user_tmp_t:s0 to unconfined_u:object_r:gkeyringd_tmp_t:s0
Would relabel /run/user/1000/keyring/ssh from unconfined_u:object_r:user_tmp_t:s0 to unconfined_u:object_r:gkeyringd_tmp_t:s0
Would relabel /run/user/1000/keyring/pkcs11 from unconfined_u:object_r:user_tmp_t:s0 to unconfined_u:object_r:gkeyringd_tmp_t:s0
Would relabel /run/user/1000/keyring/control from unconfined_u:object_r:user_tmp_t:s0 to unconfined_u:object_r:gkeyringd_tmp_t:s0


Next time: 

1. 
fixfiles verify /dev/nvidia-uvm-tools 
Would relabel /dev/nvidia-uvm-tools from system_u:object_r:device_t:s0 to system_u:object_r:xserver_misc_device_t:s0

2. 
restorecon /dev/nvidia-uvm-tools

3. (No output)
fixfiles verify /dev/nvidia-uvm-tools


Is this correct?

Comment 1 Zdenek Pytela 2023-05-02 14:59:19 UTC

(In reply to Mars from comment #0)
> #Description of problem:
> 
> Hello! I dont know is this a bug or not. I have some question please:
> Thanks for answers.
> Please do not blame me because Im using nvidia
It's not about blaming, but in case of 3rd party drivers you either need to report the issue for the vendor, or have a workaround.

> 1. Why not fix all file the `fixfiles -F onboot && reboot` command?
Not sure what is the question. Some paths are excluded from relabeling. Some are on a memory filesystem, so relabeling may not be a permanent solution.

> 2. Is this ok? `Warning no default label for /dev/mqueue`
The context is deliberately set to <<none>> as the content needs to be handled by the service which is using it.

> 3. /run/user/* and /run/Network-Manager/ context ok? (Im using built in
> wireguard vpn) 
In this particular case it is a known issue, without a solution yet.

> 4. Why and how can go wrong SELinux contexts? Why would relabel?
Typically when files are moved from a different location, keeping the previous context, but there can be more reasons.

> 
> 
> ## I run following command as root:
> 
> fixfiles -F onboot && reboot
> 
> ## After reboot, I run:
> 
> fixfiles verify
> 
> I see following output:
> 
> Verifying / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /run
> /run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug
> /sys/kernel/tracing /tmp
> Would relabel /dev/nvidia-uvm-tools from system_u:object_r:device_t:s0 to
> system_u:object_r:xserver_misc_device_t:s0
> /dev/tty2 not reset as customized by admin to
> unconfined_u:object_r:user_tty_device_t:s0
> Warning no default label for /dev/mqueue
> Would relabel /run/NetworkManager/no-stub-resolv.conf from
> system_u:object_r:NetworkManager_var_run_t:s0 to
> system_u:object_r:net_conf_t:s0
> Would relabel /run/user/1000/keyring from
> unconfined_u:object_r:user_tmp_t:s0 to
> unconfined_u:object_r:gkeyringd_tmp_t:s0
> Would relabel /run/user/1000/keyring/ssh from
> unconfined_u:object_r:user_tmp_t:s0 to
> unconfined_u:object_r:gkeyringd_tmp_t:s0
> Would relabel /run/user/1000/keyring/pkcs11 from
> unconfined_u:object_r:user_tmp_t:s0 to
> unconfined_u:object_r:gkeyringd_tmp_t:s0
> Would relabel /run/user/1000/keyring/control from
> unconfined_u:object_r:user_tmp_t:s0 to
> unconfined_u:object_r:gkeyringd_tmp_t:s0
The service which creates /run/user/1000 probably does not operate 
properly.

> 
> 
> Next time: 
> 
> 1. 
> fixfiles verify /dev/nvidia-uvm-tools 
> Would relabel /dev/nvidia-uvm-tools from system_u:object_r:device_t:s0 to
> system_u:object_r:xserver_misc_device_t:s0
> 
> 2. 
> restorecon /dev/nvidia-uvm-tools
> 
> 3. (No output)
> fixfiles verify /dev/nvidia-uvm-tools
> 
> 
> Is this correct?
We cannot do anything in selinux-policy.

Comment 2 Zdenek Pytela 2023-06-27 19:00:08 UTC

As no new information appeared during the past weeks, we are going to close this bug. If you need to pursue this matter further, feel free to reopen this bug and attach the needed information.