Bug 250881 - Incorrect ordering in rc.sysinit causes problems for encrypted partitions
Incorrect ordering in rc.sysinit causes problems for encrypted partitions
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
13
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
: 665876 (view as bug list)
Depends On:
Blocks: 229479
  Show dependency treegraph
 
Reported: 2007-08-04 00:27 EDT by Scott Wilburn
Modified: 2014-03-16 23:07 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 09:54:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/crypttab showing /tmp filesystem entry (157 bytes, text/plain)
2007-08-04 00:27 EDT, Scott Wilburn
no flags Details
Matching /etc/fstab (681 bytes, text/plain)
2007-08-04 00:29 EDT, Scott Wilburn
no flags Details
diff -u between original and modified /etc/rc.d/rc.sysconfig (2.11 KB, application/octet-stream)
2008-07-01 21:50 EDT, Scott Wilburn
no flags Details
diff for patched rc.sysinit for initscripts-8.76.4-1.i386 (2.12 KB, text/plain)
2008-10-30 08:52 EDT, Scott Wilburn
no flags Details

  None (edit)
Description Scott Wilburn 2007-08-04 00:27:40 EDT
Description of problem:

When the tmp option is used in /etc/crypttab the filesystem is created with the
proper permissions, but not the correct selinux context. The filesystem is
created with context file_t instead of the correct tmp_t. This causes problems
when selinux is enabled. In particular, installing a new kernel fails because a
making a new initrd is prevented by selinux.


Version-Release number of selected component (if applicable):


How reproducible:

Every time.


Steps to Reproduce:
1. Setup /tmp as an encrypted filesystem, using the tmp option in /etc/crypttab.
2. Reboot.
3. ls -Zd /tmp
  
Actual results:

Context of /tmp is file_t.

Expected results:

Context of /tmp should be tmp_t.


Additional info:

For a work around add to /etc/rc.d/rc.local
  /sbin/restorecon /tmp
Comment 1 Scott Wilburn 2007-08-04 00:27:40 EDT
Created attachment 160685 [details]
/etc/crypttab showing /tmp filesystem entry
Comment 2 Scott Wilburn 2007-08-04 00:29:29 EDT
Created attachment 160686 [details]
Matching /etc/fstab
Comment 3 Till Maas 2007-08-17 08:54:18 EDT
This is a bug in the initscripts, it should run restorecon or whatever the
correct selinux commandline is to create the context for newly created filesystems.

Btw. you may want to use tmpfs for /tmp instead, when you have encrypted swap.
It will first use the ram to store the contents of the fs and when there is not
enough place it uses swap. Also you should not forget /var/tmp.
Comment 4 Till Maas 2008-01-11 13:17:04 EST
Is this also a bug that won't be fixed until a new initsystem is found for Fedora?
Comment 5 Bill Nottingham 2008-01-12 00:23:23 EST
I don't see why this has to do with initscripts at all. The correct type should
be properly inhereited - we don't do restorecon on /sys or /proc....
Comment 6 Scott Wilburn 2008-01-12 13:11:59 EST
The proper contexts are:

  \    system_u:object_r:root_t
  \tmp system_u:object_r:tmp_t

So isn't the wrong type inherited upon creation and needs to be changed to match
the policy?
Comment 7 Till Maas 2008-01-12 13:37:26 EST
(In reply to comment #6)
> The proper contexts are:
> 
>   \    system_u:object_r:root_t
>   \tmp system_u:object_r:tmp_t
> 
> So isn't the wrong type inherited upon creation and needs to be changed to match
> the policy?

From manpage reading I assume that after the mke2fs the filesystem should be
mounted to e.g.
/var/tmp/temp-root-XXXXX/tmp
and then run
setfiles -r /var/tmp/temp-root.XXXXX/ /path/to/correct/selinux-context-specfile
/var/tmp/temp-root.XXXXX/tmp /var/tmp/temp-root.XXXXX/tmp/lost+found

But I do not know how to find out which selinux-context-specfile would be right.
Imho this is more or less the same as the chmod 1777 call in rc.sysinit, so it
would not be wrong to do this in rc.sysinit. Otherwise it would be nice to have
an option to mount that makes sure that the filesystem is restoreconed before it
is completely available for the system. I guess I will file an RFE for this.
Comment 8 Daniel Walsh 2008-01-14 14:10:01 EST
file_t means that a file exists on the file system without a label.  restorecon
looks at the systems defaults based on file paths and labels appropriately. 

Does the crypttab cause the file system to get created on every boot?  

If not, then labeling it once is all that is needed.  You could also use the
mount -o context=system_u:object_r:tmp_t:s0 

command line option to force the file system to be labeled tmp_t.
Comment 9 Till Maas 2008-01-14 14:36:00 EST
(In reply to comment #8)

> Does the crypttab cause the file system to get created on every boot?  

Yes, this is the case.
 
> If not, then labeling it once is all that is needed.  You could also use the
> mount -o context=system_u:object_r:tmp_t:s0 

Hm, this is a useful workaround.
Comment 10 Till Maas 2008-01-14 14:57:02 EST
(In reply to comment #5)
> I don't see why this has to do with initscripts at all. The correct type should
> be properly inhereited - we don't do restorecon on /sys or /proc....

Btw. in rc.sysinit in Fedora 7, there you already do restorecon for one dir in
/tmp, so why is it a problem to do it for the whole filesystem?

889 [ -n "$SELINUX_STATE" ] && restorecon /tmp/.ICE-unix >/dev/null 2>&1

Hm, and I also noticed that some file before this:
878 # Clean up various /tmp bits
879 [ -n "$SELINUX_STATE" ] && restorecon /tmp

So actually the code to fix this bug is already there, which leaves it unclear
whether this was wrongly reported or silently fixed.

Question to the reporter:
Do you still see this bug? Which version of initscripts do you use and how do
you run selinux, i.e. which policy and which mode (permissive or enforcing afaik)?
Comment 11 Scott Wilburn 2008-01-25 09:10:40 EST
I still see this bug, but am now running Fedora 8. I don't have access to a FC7
machine.
Comment 12 Till Maas 2008-01-25 14:27:00 EST
I guess you did not see this question:
How do you run selinux, i.e. which policy and which mode (permissive or enforcing)?
Comment 13 Scott Wilburn 2008-01-26 13:45:53 EST
I am running the targeted policy in enforcing mode.
Comment 14 Scott Wilburn 2008-01-26 13:46:21 EST
initscripts-8.60-1
Comment 15 Bug Zapper 2008-05-14 09:51:55 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bill Nottingham 2008-05-29 09:45:48 EDT
Out of curiousity, what happens if you apply the change in:

http://git.fedorahosted.org/git/initscripts.git?p=initscripts.git;a=commit;h=60ae2cf1f6494b3036f1126f88f71f0ab77e5e74
Comment 17 Scott Wilburn 2008-05-29 22:59:17 EDT
That didn't help, but I notice another clue. During the init process, there are
errors just after the message:

  Remounting root filesystem in read-write mode: " mount -n -o remount,rw

that say that /dev/mapper/tmp and /dev/mapper/var-tmp do not exist. They do
eventually mount, however, since they appear as mounted after the system is
fully started. Is it possible they are not mounted at the time restorecon is
run, perhaps because disk encryption is not started early enough during init?
Comment 18 Scott Wilburn 2008-07-01 21:48:27 EDT
Changing version to F9.

The problem is due to to problems in rc.sysinit

1. The RNG is started after local file systems are mounted. If, as in my case,
/tmp and /var/tmp are encrypted with random keys, these aprtitions can't be
mounted at the correct time. Moving the RNG initialization to just before
mounting local file systems fixes this problem. However, logic to mount /var
first, it it is not part of the root partition is also needed so the RNG can
have /var/lib/random-seed is also needed to cover all cases. I haven't done this.

2. /var/tmp needs to be added to the restorecon command that operates on /tmp as
part of the "Clean up various /tmp bits" section. This sets the proper context
for /var/tmp as well as /tmp.

I'll attach a diff against rc.sysinit.
Comment 19 Scott Wilburn 2008-07-01 21:50:36 EDT
Created attachment 310746 [details]
diff -u between original and modified /etc/rc.d/rc.sysconfig
Comment 20 Scott Wilburn 2008-09-17 09:12:30 EDT
Updating summary to better match problem.
Comment 21 Scott Wilburn 2008-09-25 09:13:16 EDT
Problem still exists in initscripts-8.76.3-1.i386
Comment 22 John Poelstra 2008-10-12 16:52:54 EDT
This bug has been triaged
Comment 23 Scott Wilburn 2008-10-30 08:50:39 EDT
diff -u between original and modified /etc/rc.d/rc.sysconfig for 
initscripts-8.76.4-1.i386
Comment 24 Scott Wilburn 2008-10-30 08:52:25 EDT
Created attachment 321925 [details]
diff for patched rc.sysinit for initscripts-8.76.4-1.i386
Comment 25 Bug Zapper 2009-06-09 18:44:23 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Kevin R. Page 2009-09-11 14:20:02 EDT
The comment #24 doesn't cleanly apply, but I tried hacking rc.sysinit such that "Initialize pseudo-random number generator" and "if [ -f /etc/crypttab ]" were before "Mount all other filesystems", 

I guess there have been other changes in rc.sysinit

F11 initscripts-8.95-1.i586
Comment 27 Bug Zapper 2010-04-27 07:45:31 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 Kevin R. Page 2010-08-02 19:01:27 EDT
Still seems to be an issue on F13 -- at least, enabling a tmp option in /etc/crypttab doesn't result in that device being available and active in /dev/mapper.
Comment 29 Bill Nottingham 2011-01-03 11:43:33 EST
*** Bug 665876 has been marked as a duplicate of this bug. ***
Comment 30 Bug Zapper 2011-06-02 14:40:27 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 31 Bug Zapper 2011-06-27 09:54:50 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.