On Mon, 2025-11-10 at 07:52 -0500, Sam Varshavchik wrote: > According to Google Skynet, Fedora Core 3 was the first release that had > SELinux enabled by default. > > That was more than 20 years ago. > > I think that 20 years is more than long enough for this kind of technology > to mature, and work the kinks out, and then it's smooth sailing from that > point on.
You'd think... I also find I get oddball SELinux screw-ups, and many have nothing to do with me. Looking at the old CentOS box I'm playing with right now, there's one about /usr/sbin/ModemManager being denied dac_override. I don't have a modem. Another about cups-pk-helper- and being denied reading cups.sock, heck knows what that's about, but it sounds like it can't do something with its own systems. Another where cachemgr.cgi wasn't allowed to search /etc/squid (cachemgr is a squid program). Another where fetchmail wasn't allowed to write its pid. Looking at Fedora 42, I have three recent ones. Python trying to dac_read_search on this capability (with *NO* information showing there), likewise with polkit-agent-helper-1 trying dac_override and dac_read_search (both with no information in the capability field). If you click on the details button to get more than just this quick summary, it's highly opaque. It's not written in user-language, but obscure programming nerd with a peculiar mindset. # semodule -i my-ModemManager.pp Additional Information: Source Context system_u:system_r:modemmanager_t:s0 Target Context system_u:system_r:modemmanager_t:s0 Target Objects Unknown [ capability ] Source ModemManager Source Path /usr/sbin/ModemManager Port <Unknown> Whoever thought up the names of the contexts did a rotten job of making them self-explanatory. And nobody ever came up with a GUI tool for setting them. Sure, that might be hard to do for some of these really oddball ones. But when you'd doing obvious things like putting a file in a web server directory and need to make it world readable, how hard would it have been to have some appropriate SELinux context setting options along with the usual rwxrwxrwx- permission setting boxes? Or that that setting something WORLD READABLE actually did what you expected. I've lost count the number of times that the obvious doing a drag-n- drop of a JPEG from somewhere into /var/www/html/images (for example) results in spurious HTTP error due to a SELinux context being wrong, but the HTTP error is misleading (you can see the file IS where the server expects to find it, and IS world readable, there's further HIDDEN controls restricting access to it). Yet, other times that (drag-n-drop) works fine. Having to resort to the command line to fix things up after using a graphical tool is a crappy workflow. Not to mention that you're even more likely to screw them up from the command line, because you're probably going to "mv" instead of "cp" a file into place, and moving a file carries its original contexts, whereas copying it gives it the usual defaults for the destination. It's no wonder that so many "help guides" on the internet began with first disable SELinux. -- uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 (yes, this is the output from uname for this PC when I posted) Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
