|Summary:||lost+found directories on newly created file systems have no SE Linux labels|
|Product:||[Fedora] Fedora||Reporter:||Russell Coker <rcoker>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||dwalsh, kzak, sct|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-10-18 21:43:28 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Russell Coker 2005-05-16 12:24:21 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.0 (like Gecko) Description of problem: After a default install of Fedora with SE Linux enabled the lost+found directory has no label. To fix this restorecon must be run for each file system, eg: restorecon /lost+found /boot/lost+found ... Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Install Fedora and run "ls -ldZ /lost+found". Actual Results: drwx------ root root /lost+found/ Expected Results: drwx------ root root system_u:object_r:lost_found_t /lost+found/ Additional info:
Comment 1 Jeremy Katz 2005-05-16 20:47:17 UTC
Aren't these supposed to be created with sane label'ing by mke2fs? I seem to remember that being the answer...
Comment 2 Russell Coker 2005-05-16 20:55:38 UTC
mke2fs has no knowledge of SE Linux (not linked against libselinux) and it's probably not desirable that it get such knowledge. If mke2fs knew about SE Linux then that wouldn't entirely solve the problem, I'm not certain that we will always want the same type for lost+found and the regular file_contexts file should be used for best functionality which requires knowledge of the mount point (that mke2fs doesn't have). We already have some code somewhere that causes the root directory of the file system to get labeled correctly, the same code needs to label the lost+found directory.
Comment 3 Jeremy Katz 2005-05-19 01:09:39 UTC
Dan, I know we had this conversation at some point. I just don't remember what the outcome was. It's not really practical to do labeling of a random dir in any of a number of arbitrary mountpoints.
Comment 4 Jeremy Katz 2005-05-23 17:44:34 UTC
Having anaconda do this isn't really reasonable. A user will have the same problem if they later create a filesystem and then don't run fixfiles on it.
Comment 6 Russell Coker 2005-06-13 12:53:46 UTC
Regarding the issue of "A user will have the same problem if they later create a filesystem and then don't run fixfiles on it", the user will also have the same problem with the root directory of the file system in question. After mounting a new file system restorecon (or some equivalent operation) has to be run by the user. Regarding the "It's not really practical to do labeling of a random dir in any of a number of arbitrary mountpoints" issue, lost+found is a special case, it's not a random dir. This only requires changing a mount operation to a mount plus a restorecon.
Comment 8 Jeremy Katz 2005-06-21 17:28:08 UTC
restorecon can take an arbitrary amount of time depending on what's on the filesystem. We *CANNOT* add a "well, this is going to take some random amount of time" to the installer. Per Dan, this is something that needs to be resolved at the SELinux level, not by hacking anything that might ever call mount(2). If the answer is that it has to be done on mount(2), then the kernel should be doing it.
Comment 9 Russell Coker 2005-06-22 03:57:56 UTC
The amount of time taken by restorecon is determined directly by the number of files and directories that it needs to process. If lost+found has any sub-directories or files at install time (the only case in which restorecon would take more than about 100ms) then we have really serious problems that will probably result in the machine being trashed anyway.
Comment 10 Russell Coker 2005-06-22 06:17:40 UTC
One thing I forgot to mention. If you don't use the -R switch then restorecon won't descend subdirectories. So even in the case of an install to a machine with significant problems that manages to get a full lost+found on install restorecon will only need to update one Inode. The operation of restorecon is to read /etc/selinux/config, read the file_contexts file, stat whichever file system objects are specified on the command-line, do a small amount of computation (considerably less than 1 second of CPU time) and then write a single xattr. The operations that restorecon performs are a small sub-set of the operations that rpm performs to install a single package.
Comment 11 Chris Lumens 2006-06-02 19:11:13 UTC
/lost+found directories are currently being labeled system_u:object_r:file_t. Have we come to any consensus about what the right thing to do is?
Comment 12 Jeremy Katz 2006-06-04 18:35:59 UTC
I really think that the right thing here is probably having mke2fs do it if anything...
Comment 13 Eric Sandeen 2007-10-17 21:54:26 UTC
i'm not convinced that mkfs should be doing this. For starters, maybe you want different labels on /foo/lost+found than on /bar/lost+found. mkfs has no idea where the filesystem it's creating will be mounted.... file_contexts has whole paths, not rules based on relative directories under a filesystem root inode, near as I can tell* *disclaimer - I'm no selinux guru by far.
Comment 14 Eric Sandeen 2007-10-17 22:00:47 UTC
Or, for example, take the label on the root inode. if the new fs will be mounted on /tmp, it gets a different label than if it were to be mounted on /var I don't see how this can be mkfs's job.
Comment 15 Daniel Walsh 2007-10-18 14:14:39 UTC
Since this bug never seems to go away and there is no real good solution. I think the best we could do is take the file context of /lost+found and apply that to any lost+found we create. This will be correct for targeted polciy/mls policy and probably just about any policy we create. If someone else wants to do something different, they can just do a restorecon. pseudocode con = matchpathcon("/.lost+found",DIRSTAT); setfscreatecon(con); mkdir("/.lost+found"); setfscreatecon(NULL);
Comment 16 Eric Sandeen 2007-10-18 14:57:13 UTC
No need to fixate on lost+found/ : [root@localhost ~]# ls -Zd /tmp drwxrwxrwt root root system_u:object_r:tmp_t:s0 /tmp [root@localhost ~]# mkfs.ext3 fsfile ... [root@localhost ~]# mount -o loop fsfile /tmp [root@localhost ~]# ls -Zd /tmp drwxr-xr-x root root system_u:object_r:file_t:s0 /tmp root inode context is now wrong. There is no way mkfs can know what the root inode context should be. I dont'see any way to properly set contexts from mkfs; it has to be done after it's been mkfs'd and mounted, near as I can tell.
Comment 17 Eric Sandeen 2007-10-18 15:23:10 UTC
I'm gonna NOTABUG this. mkfs cannot set new filesystem contexts; it must be done post-mount because the contexts depend on the path. I'd say this is not a bug, it's expected, and requires administrative action to set these properly. If anyone disagrees, please reopen w/ rationale.
Comment 18 Daniel Walsh 2007-10-18 21:28:05 UTC
I agree this is anaconda's responsibility. Reopenging and changing the owner
Comment 19 Eric Sandeen 2007-10-18 21:43:28 UTC
In the meantime, this was fixed under bug #335621 (I only notabug'd this because it wasn't originally in the anaconda context) *** This bug has been marked as a duplicate of 335621 ***
Comment 20 Eric Sandeen 2007-10-18 22:11:18 UTC
... or maybe it was... anyway, anaconda should be fixing this up now!