Aren't these supposed to be created with sane label'ing by mke2fs?  I seem to
remember that being the answer...

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. 

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.

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.

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. 

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.

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. 

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. 

/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?

I really think that the right thing here is probably having mke2fs do it if
anything...

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.

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.

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);

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.

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.

I agree this is anaconda's responsibility.  Reopenging and changing the owner

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 ***

... or maybe it was... anyway, anaconda should be fixing this up now!