> From: Bill Nottingham [mailto:notting@xxxxxxxxxx] > > Joshua Brindle (jbrindle@xxxxxxxxxx) said: > > > Yes, but that tends to imply some fairly severe gun -> foot > > > interactions on the part of the admin. > > > > The admin need not know what is going on, how many things happen on > > average linux systems without an average admins knowledge? > > Well, I'd hope that remounting the root FS read-write > wouldn't be one of those. Arguably, you could even set up the > policy to disallow this. > > > I retract the above statement. Even when making > non-persistent boolean > > changes (which I can see happening on these systems) the lock is > > attempted. Its still unclear whether setsebool should > fallback or if > > libsemanage should. I don't like the idea of lockless > readers, even if > > the filesystem is RO when we start reading. > > Hm, I didn't consider booleans. How (at an implementation > level) is setting of booleans done? (I've haven't looked at > the backend guts of the SELinux code that much.) > In the non-persistent case it checks whether the store is managed and then does the libselinux calls to set the boolean so that actually won't be a problem. Also, Karl claims that lockf works on a RO filesystem so the actual problem is that we always open the lock file with O_RDRW | O_CREAT but we can change it to try a read only open first and if it isn't there try to create it and then bail after that. If the store has been properly initialized the lock files will be present, the O_RDONLY open will succeed and the lockf call will succeed and the query should work fine. This is a pretty trivial change, do you think it will work Steve? -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
