Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 157833

Summary: lost+found directories on newly created file systems have no SE Linux labels
Product: [Fedora] Fedora Reporter: Russell Coker <rcoker>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dwalsh, kzak, sct
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-18 21:43:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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:

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 

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

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 

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

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.

con = matchpathcon("/.lost+found",DIRSTAT);

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!