Should sysfs_t be split into more fine graded contexts?

[TomasKorbar]

Hi,
recently i have been debugging AVC denial that started occurring since Fedora 39 for my daemon written in Python.
I tracked down the issue to blake2 library's dependency on libgomp library which tries to find number of available CPUs by
reading of /sys/devices/system/cpu/possible. Seems like a valid use case for a library that provides support of parallel programming. The issue is that /sys/devices/system/cpu/possible file has sysfs_t context and thus if you want to satisfy this request, you give the daemon access to a lot more information than just how many CPUs the system has.
So my question is, shouldn't be there a separate context for CPU or perhaps more devices?

[zpytela]

Hi Tomas,
You are right the policy should be more fine-grained in /sys, especially when the write permission is needed, but it's currently not implemented this way.
Please use interfaces when accessing types from other modules, like dev_read_sysfs() or request creating new ones.