On Mon, May 12, 2008 at 02:04:56PM +0100, Jonathan Underwood wrote: > Dear Daniel, > > Any chance you could cast your eye over: > > https://bugzilla.redhat.com/show_bug.cgi?id=437633 > > In brief, there's a bad interaction between gam_server and selinux > which is breaking fail2ban. The issue is, if some process starts a > gam_server as UID root it will be assigned a SElinux domain according > to the process that started gam_server. If another UID root process > tries to connect to the socket of that first gam_server, according to > the gamin logic it should be allowed, since the UID is correct.
yes that's the logic, based on the needs for the desktop that was put into gamin design. > However, the second process fails to connect because it has a > different SElinux domain. In other words, can gam_server be made > SElinux aware? Your thoughts would be much appreciated! Honnestly, gamin is in very low priority maintainance mode ATM, and i have no experience of what it takes to 'make gam_server SElinux aware'. It was really designed so that each user gets a different server, and when different programs runs for the same user they share the access. The fact that gam_server got started because application A or application B on the desktop needed the monitoring feature should not matter, they really should share the instance. We really do not want to see a gam_server for nautilus, one for firefox, etc... The server is dynamically started by the first app needing FAM, the others connect based on the user ID being shared. the whole security design of gamin is based on the assumption that all process running for a given UID share their filesystem permissions and hence can share the gam_server instances. As a result the server runs under the ID of the given user. SELinux adds an extra set of arbitrary boundaries, this wasn't expected at gamin design time. i don't know how that could work with the current principles of FAM/gamin use for all the desktop and systems applications. I would really prefer if that could be fixed at the policy level, if not, it probably mean way more than just popping new gam_servers around each time there is a failure. Gamin is horribly hard to debug already, stuck between broken kernel APIs and a broken FAM library API, I wish a lot of luck to anybody who would like to take over, fix it or rewrite it... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
