problems with tmpfs and relabeling

[Joshua Brindle]

> From: Bill Nottingham [mailto:notting at redhat.com] 
> 
> Joshua Brindle (jbrindle at tresys.com) said: 
> > > Likely, but we'd want to distinguish the ro mount case from a rw 
> > > mount where the read lock acquisition fails for some 
> other cause.  
> > > Likely can just test for errno EROFS when
> > > semanage_get_active_lock() fails, and proceed with rdonly 
> operations 
> > > in that case?  cc'd Tresys folks above.
> > 
> > Not sure about this, if the mount becomes rw in the middle 
> of a EROFS 
> > read the policy can changed underneath them.
> 
> 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?

> > I guess I'm unsure where
> > this sudden push for ro filesystem support is coming from 
> and why its 
> > important. Any kind of read only / system is going to have a highly 
> > abstracted interface. I have serious doubts that there would be any 
> > users running a bash shell and trying to get a list of modules.
> 
> http://fedoraproject.org/wiki/StatelessLinux
> 

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. 

I'm open to suggestions, the easiest thing to do in this case is
propagate the EROFS error back up to setsebool to fall back but that
doesn't address the other semodule/semanage operations, but I'm dubious
as to whether those are useful at all on a setup like this.