From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061011 Fedora/1.5.0.7-7.fc6 Firefox/1.5.0.7 Description of problem: Run a system with multiple Versions of Fedora, but all mount the same /home partition. So far this system always worked (from core 3 to core 6). Recently tried to install core 8 using a live CD version. This also insrtalled SElinux (visible from _t messages when restarting the network ARping). However when rebooting back into Core 6, /home/* was no longer writable to anyone, including root. /home itself was still writable. a cp -Rp to a new disk and then mounting that as /home reolved the problem. Suspect SElinux puts a mark on the disk that avoids the other (older) OS to write although not able to find it Have not reproduced it, but still have the old /home disk in itΕ broken state (still can mount this disk such that i can write on it..) Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional info: Rather strange to mount a system RW, see all flags as 755 Ie writable files, but still no chance to modify the files, not even as root.
If you put the machine in permissive mode, can you access it? Fedora 6 should be able to read a Fedora 8 file system. Some labels might be treated as unlabeled_t but an unconfined user should still be able to use them.
Sorry, unclear. 1) fedora core 8 installed 'automatically' with SE linux, and can access the disk that is mount as /home [read and write access]. rebooting (same machine)into Core 6, mounting the same disk as /home (core 6 does not have SElinux activated) makes the complete disk readable, but not writable; not even to root. Obviously prior to installing core 8 /home was perfectly accesible (not only to root!) under core 6. ie I had a disk that was at that moment only accessible/mounted by Fedora core 6, it was mounted RW, protection settings were 755 and still no write acess to anyone on core 6 Added note a cp -pR /home/* to a new disk, and mounting that as home means /home is again writable in core 6. The specific disk remained write protected until I reformatted it
So this is probably not an SELinux issue but a kernel issue. SELinux would not have changed the file system on Fedora 8 from that of Fedora 6. And disabling Fedora 6 seems to still have had the problem. I will reassign, maybe someone there will have an idea.
eric, any ideas ? Frans, I'm assuming you're using ext3 ?
Frans, so I assume that when you go back to F8 you can read/write /home again, right? it's only un-writable under FC6? And under FC6 "getenforce" says disabled? Can you include the tail of dmesg after you mount the fs under F6? Perhaps you have some read-only-compatible features enabled; can you also attach "tune2fs -l $DEVICE" output? Thanks, -Eric
Eric, Indeed, under core 8 it was still writable. /var/log/messages probably showed picking this up from the log file and 100 percent sure about the timing Apr 27 17:16:45 thebridge kernel: inode_doinit_with_dentry: context_to_sid(unconfined_u:object_r:unconfined_home_t:s0) returned 22 for dev=sda7 ino=836354 there are about a zillion lines (1293 to be exact) with this returned 22... Output of tune2fs probably no longer valid as I reformatted the disk (to avoid further complications with to userspaces starting to run out of Sync. If really needed could try to turn SElinux back on on core 8 to see whether i can reproduce the error (preferably on another disk as /home) Interesting enough the XFS file system did not seem to have troubles..)
> Apr 27 17:16:45 thebridge kernel: inode_doinit_with_dentry: context_to_sid(unconfined_u:object_r:unconfined_home_t:s0) returned 22 for dev=sda7 ino=836354 That was under F6? And was it when you tried to write? > Output of tune2fs probably no longer valid as I reformatted the disk Hm, probably our only hope to narrow down exactly what was going on... > Interesting enough the XFS file system did not seem to have troubles... No, I wouldn't expect it to.... unless this were some generic selinux thing... this probably rules that out. I'll ponder the selinux message, and double check any read-only flags that were introduced between FC6 and F8, but I don't think there were any... This may wind up as needing to be closed for lack of info, I'm afraid, but I'll see if I can come up with any theories.
Stumbled on this bug looking for another. esandeen found the problem and didn't know it. > Apr 27 17:16:45 thebridge kernel: inode_doinit_with_dentry: context_to_sid(unconfined_u:object_r:unconfined_home_t:s0) returned 22 for dev=sda7 ino=836354 So in F8 the honedir was labeled with an selinux label unconfined_u:object_r:unconfined_home_t:s0 but this label didn't exist in F6. So even root would be unable to access those files because we don't give permissions on invalid labels. restorecon -R /home between every F8 -> F6 switch should deal with the question. You could also change the F6 fstab to include context=system_u:object_r:user_home_t for the /home mount. That should allow both F6 and F8 to be able to get at the same FS. F6 doesn't understand the labels in F8. Nothing we can really do to change that. Sorry!