Bug 729452 - auditd chkconfiged off at run level 5
Summary: auditd chkconfiged off at run level 5
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: readahead
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Harald Hoyer
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1002711
TreeView+ depends on / blocked
 
Reported: 2011-08-09 19:00 UTC by Giacomo G. Brussino
Modified: 2019-06-13 07:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-07 01:45:12 UTC


Attachments (Terms of Use)
/var/lib/readahead/custom.early at the first boot (63.06 KB, application/octet-stream)
2011-08-16 05:43 UTC, Féliciano Matias
no flags Details
/var/lib/readahead/early.sorted at the first boot (70.94 KB, application/octet-stream)
2011-08-16 05:44 UTC, Féliciano Matias
no flags Details

Description Giacomo G. Brussino 2011-08-09 19:00:46 UTC
Description of problem: auditd is checkconfiged off at run level 5 after a RHEL 6.0 workstation x86_64 install; same after upgrade to RHEL 6.1


Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Workstation release 6.1 (Santiago)

How reproducible: install RHEL 6.0 from media. Register with rhn. Upgrade to 6.1.


Steps to Reproduce:
1. Installed RHEL 6.0 x86_64 workstation from media
2. Register with rhn
3. Upgrade to RHEL 6.1
  
Actual results:
[root@auroranew etc]# service auditd status
auditd is stopped
[root@auroranew etc]# chkconfig --list auditd
auditd         	0:off	1:off	2:on	3:on	4:on	5:off	6:off
[root@auroranew etc]# grep chkconfig /etc/init.d/auditd 
# chkconfig: 2345 11 88
[root@auroranew etc]# 

Expected results:
[root@auroranew etc]# chkconfig --list auditd
auditd         	0:off	1:off	2:on	3:on	4:on	5:on	6:off
[root@auroranew etc]# service auditd status
auditd (pid  11118) is running...
[root@auroranew etc]# 


Additional info:

Comment 2 Steve Grubb 2011-08-12 11:35:34 UTC
I am at a loss in explaining how this could have happened. As you show above, the init script says to be on in runlevels 2345. The initscript is identical to the initscript used in Fedora and no one has reported this problems there. The spec file only adds or deletes the initscript and does not mess with an individual run level. So...I don't know how this would happen.

Comment 3 Féliciano Matias 2011-08-15 20:46:41 UTC
I installed Scientific Linux 6.1 some days ago and hit this bug.
I try to reproduce it with kvm.

I create a new kvm virtual host with virt-manager (here with Scientific Linux 6.1) and keep all the default values except :
- Memory (RAM) : 1024 MB (this trigger a graphical installation)
- OS type : Linux
- Version : Red Hat Enterprise Linux 6
- Use ISO image : http://mirrors.ircam.fr/pub/scientificlinux/scientific/6.1/x86_64/os/images/boot.iso

Install and keep all the default values as much as possible.
When the installation method is request, enter :
- URL
- URL containing the installation image : http://mirrors.ircam.fr/pub/scientificlinux/scientific/6.1/x86_64/os

Comment 4 Steve Grubb 2011-08-16 01:44:36 UTC
By any chance, do you have the readahead service enabled? It disables the audit system so it can see file access on startup.

Comment 5 Féliciano Matias 2011-08-16 05:43:38 UTC
Created attachment 518398 [details]
/var/lib/readahead/custom.early at the first boot

/var/lib/readahead/custom.early at the first boot (network install, Desktop installation).

Comment 6 Féliciano Matias 2011-08-16 05:44:34 UTC
Created attachment 518399 [details]
/var/lib/readahead/early.sorted at the first boot

/var/lib/readahead/early.sorted at the first boot (network install, Desktop installation).

Comment 7 Féliciano Matias 2011-08-16 05:45:48 UTC
Hope it's what you want, see attachements 518398 ans 518399.

After the installation and before the first boot, auditd is enabled at run level 5. At the end of the first boot this is not more the case.

I tested the installation "minimal" and "web server", auditd is enabled.

Comment 8 Steve Grubb 2011-08-16 13:18:41 UTC
If you have readahead installed and you care about auditing, remove the readahead package. You won't be able to get bootup events with it installed and working properly, and you might have audit disabled if it doesn't work properly.

Comment 9 Giacomo G. Brussino 2011-08-16 15:15:21 UTC
I confirm that readahead was installed.
Thank you, Steve.

Comment 10 Féliciano Matias 2011-08-17 00:00:34 UTC
(In reply to comment #8)
> If you have readahead installed and you care about auditing, remove the
> readahead package. You won't be able to get bootup events with it installed and
> working properly, and you might have audit disabled if it doesn't work
> properly.

Ok, I check the package readahead, it temporally disable auditd if /.readahead-collect exist. It's not a "brilliant" job (but I am not a developer and I don't understand all the subtleties of Linux.).

If firstboot is launched and you reboot the computer without filling firstboot (switch to other console for example and "reboot" because you are waiting for some informations), auditd is deactivated for the current run level. If there is a power failure during the boot sequence and readahead-collector is doing its job, auditd is deactivated, and so on. normal ? Why providing readahead and auditd in the *defaut* installation (activated by default) if they can't work together ? Readahead can deactivate auditd, setroubleshoot should deactivate readahead if you install it (setroubleshoot depend on auditd).

For me readahead should not change the configuration if he is not able to restore the configuration in case of failure. But it's the (flaw) design of readahead. Bug or not ? Not a bug of audit anyway.



Ignore my tests with a virtual host because I was checking the configuration of auditd with firstboot running.

Comment 11 Steve Grubb 2011-08-17 12:58:54 UTC
Transferring this to readahead component to see if this could be made more robust. I almost think audit and readahead should conflict, but I suppose it all depends on what the chkconfig settings are.

Comment 12 RHEL Product and Program Management 2011-08-17 13:09:06 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 13 Harald Hoyer 2011-08-17 13:27:17 UTC
(In reply to comment #11)
> Transferring this to readahead component to see if this could be made more
> robust. I almost think audit and readahead should conflict, but I suppose it
> all depends on what the chkconfig settings are.

right, if readahead is enabled and the collect job is running, it delays auditd startup by temporarily disabling auditd, and enabling and starting it afterwards.

Comment 14 Harald Hoyer 2011-08-17 13:28:18 UTC
In Fedora, readahead is obsoleted by systemd-readahead, which uses the new fanotify mechanism.

Comment 15 Harald Hoyer 2011-08-17 13:32:55 UTC
I will look into making it more robust against power failures and such.

Comment 16 Féliciano Matias 2011-08-17 20:06:01 UTC
(In reply to comment #15)
> I will look into making it more robust against power failures and such.

A proposal.
Change also the init scripts of auditd and don't touch /etc/rc.d/ symbolic links.
Don't forget I am not a developer !


readahead-collector
star :
  touch /var/lock/subsys/readahead-auditd
stop :
  rm /var/lock/subsys/readahead-auditd


auditd
star :
  if /var/lock/subsys/auditd then exit
  touch /var/lock/subsys/auditd
  if /var/lock/subsys/readahead-auditd exist then
    call wait_for_readahead_background()
    exit
  endif
  as usual

stop :
  as usual (rm /var/lock/subsys/auditd)

status :
  if /var/lock/subsys/readahead-auditd then
    echo "waiting for readahead"
  else
    as usual
  endif

wait_for_readahead_in_background() {
  wait_for /var/lock/subsys/readahead-auditd
  if not /var/lock/subsys/auditd then exit
  rm /var/lock/subsys/auditd
  /sbin/service auditd start
}


Not perfect, but this should support a power failure and this doesn't touch de configuration.

Comment 17 Jeroen Beerstra 2012-07-28 11:25:02 UTC
Same problem here, but in runlevel 3 (my default). This sums it up:

Good:

Jul 27 15:56:37 trinity kernel: readahead-collector: starting
Jul 27 15:56:37 trinity kernel: readahead-disable-service: delaying service auditd
Jul 27 15:59:39 trinity kernel: readahead-collector: starting delayed service auditd 3
Jul 27 15:59:40 trinity kernel: readahead-collector: sorting
Jul 27 15:59:43 trinity kernel: readahead-collector: finished

Bad:

Jul 27 05:53:47 trinity kernel: readahead-collector: starting
Jul 27 05:53:47 trinity kernel: readahead-disable-service: delaying service auditd
Jul 27 05:54:26 trinity kernel: readahead-collector: sorting
Jul 27 05:54:27 trinity kernel: readahead-collector: finished

Comment 21 Andrius Benokraitis 2013-10-07 01:45:12 UTC
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6, and will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.


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