Bug 617321 - Providing native systemd file for upcoming F14 Feature Systemd
Summary: Providing native systemd file for upcoming F14 Feature Systemd
Alias: None
Product: Fedora
Classification: Fedora
Component: audit (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Steve Grubb
QA Contact: Fedora Extras Quality Assurance
: 714447 (view as bug list)
Depends On:
Blocks: SysVtoSystemd
TreeView+ depends on / blocked
Reported: 2010-07-22 19:02 UTC by Jóhann B. Guðmundsson
Modified: 2011-09-09 15:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-09-09 15:26:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Native systemd file for auditd (195 bytes, text/plain)
2010-07-22 19:02 UTC, Jóhann B. Guðmundsson
no flags Details
Spec file which introduce systemd unit file and drop SysV support for auditd.service (15.99 KB, text/plain)
2011-06-24 09:45 UTC, Jóhann B. Guðmundsson
no flags Details
Spec file patch for auditd (1.65 KB, patch)
2011-07-26 21:41 UTC, Jóhann B. Guðmundsson
no flags Details | Diff

Description Jóhann B. Guðmundsson 2010-07-22 19:02:52 UTC
Created attachment 433779 [details]
Native systemd file for auditd

Description of problem:

The attached file is a native systemd file for upcoming F14 Feature [1]

Please read [2] on how to installing systemd Service files.


If you have any question dont hesitate to ask them on this bug report.

Thank you.

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Steve Grubb 2010-07-23 16:09:17 UTC
Few questions.

1) How is resume, rotate, and reload supported in systemd?

2) Auditd is a security sensitive component and quite a few services should
wait until its running before they start: sshd, login, crond, gdm, kdm, xdm,
vsftpd, raccoon, dbus, amtu, cups, and nscd. There are probably more.

3) Does systemd meet our security requirements?

a) We must record system startup/shutdown/runlevel changes to the audit system.
b) We must record the startup of any service - even if it fails to the audit
c) We need "service foo start" to tell init to do the startup so that anything 
in the admin's session does not get into the service's environment. There are 
things in the processes' task structure in the kernel that get leaked.


Comment 2 Steve Grubb 2010-07-29 14:48:11 UTC
Any comments on the above security requirements?

Comment 3 Bug Zapper 2010-07-30 12:45:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 4 Lennart Poettering 2010-08-10 14:19:32 UTC
Regarding 1) -- systemd's systemctl tool only understand the verbs necessary for maintaing the service at runtime. Additional verbs available in the various init scripts cannot be used with systemctl. But that should be fine. For now it should be fine if the user would simply call /etc/init.d/auditd for this as he always did.

(Note that I am not a particular fan of these additional verbs which just send a signal. The verbs should be synchronous and return only after the operation completed, but sending a signal is asyncrhonous and returns immediately).

In the long run I think it would make sense to provide a dedicated client utility that does these operations synchronously and without involving the init script.

Regarding 2) the services you listed, why exactly to they need auditd? Do they communicate with auditd? how does that communication work? is it AF_UNIX based? or AF_NETLINK based? Usually if it is AF_UNIX based my recommendation would be to make auditd socket activatable which would allow us to start it in parallel with the clients wanting to talk to it, without further synchronization. If that is not possible we can add explicit synchronization however, by adding "After=auditd.service" to the various service files of the various unit files, or something similar to the LSB headers (where it should already be available anyway?)

Regarding 3): well, we carry a number of selinux patches already, so there has been work in this direction.

regarding a) it would be easy to add this i presume. I see no code for this in upstart, how is this done right now? We have no notion of runlevels anymore. How free-form is this? if you point me to some example code I am happy to prep a patch for this.

regarding b) we record this anyway, so forwarding this to auditd should be easy (and much nicer then with sysv). if you point me to some example code, i'd be happy to hack this up, too. How does the communication work here? i.e. we probably need to avoid deadlocks here that we try to notify audit that audit has started and so on.

regarding c) systemd guarantees a completely clean execution environment for all the services it starts. The processes are forked off PID 1 and hence do not inherit anything from the users shell where he might run "systemctl start apache.service" from.

Does that answer your questions?

Comment 5 Bill Nottingham 2011-04-26 17:35:55 UTC
Moving systemd service RFEs to rawhide.

At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades.

We therefore request:
- wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes.
- work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release.
- do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy

Comment 6 Elad Alfassa 2011-06-19 11:18:12 UTC
*** Bug 714447 has been marked as a duplicate of this bug. ***

Comment 7 Jóhann B. Guðmundsson 2011-06-23 13:47:36 UTC
What's the current status on this and note as per packaging guidelines the old sysv init script would be packed in a separate subpackage if the intention is to continue to maintain and support.


Comment 8 Jóhann B. Guðmundsson 2011-06-24 09:45:49 UTC
Created attachment 509720 [details]
Spec file which introduce systemd unit file and drop SysV support for auditd.service

Spec file which introduce systemd unit file and drop SysV support for

I threw in here a spec file which introduce systemd unit file and drop SysV
support for the submitted auditd.service encase there continues to be no move on this report so we dont end up blocking the alpha release you can then update
the service file with what ever the final outcome will be went.

Note that this spec file will remove the old sysv init script if you have any intention of continuing supporting the legacy sysv init script you will need to update this spec and package the legacy sysv script separately in a sub package as stated by the packaging guidelines.

Comment 9 Steve Grubb 2011-06-24 14:25:37 UTC
The status on this bug is that I need to get support for systemd upstream. After that is worked out, I'll build for rawhide.

But I was also curious if everything that uses the audit system has their After= set to the audit system? That would be things like: sshd, gdm, kdm, xdm, crond, vsftpd, dbus, and login. There may be a couple others like rshd, but its so rarely used I don't know if its patched offhand.

Comment 10 Jóhann B. Guðmundsson 2011-06-24 14:43:28 UTC
Nope not to my knowledge hence it's so important that we push out an services as soon as possible so we can catch those After= and Before= is the submitted service file not good enough to be pushed to rawhide or do we explicitly need to wait after systemd gets patched ?

Comment 11 Jóhann B. Guðmundsson 2011-06-24 19:03:36 UTC
Oh yeah I should mention it's probably best that you add all the service that need to be mounted after auditd.service to a Before=<list of service file ) line in auditd.service  as opposed to them add it to their native systemd service file as in the form of After=auditd.service

Comment 12 Jóhann B. Guðmundsson 2011-07-11 13:50:10 UTC
two+ weeks has passed any updates?

Are you and Lennart working together solving the technical issues regarding this ?

Comment 13 Steve Grubb 2011-07-11 13:56:52 UTC
I am planning to release a new audit package in the next few weeks. That one will have the systemd based init script.

Comment 14 Jóhann B. Guðmundsson 2011-07-11 14:11:02 UTC
Hum how long is next few weeks as in will it be done before the "Alpha Change Deadline" ( 2011-08-02) Preferable a week before ( 26 July ) to not to disturb the regular QA process to much?

Comment 15 Jóhann B. Guðmundsson 2011-07-26 14:37:47 UTC
Will this be ready for thursday?

Comment 16 Steve Grubb 2011-07-26 14:58:09 UTC
I will see what I can do. I have much more important things to do right now. I have decided that upstream will not support systemd at this point. There are too many issues that are unclear to be able to support both traditional and this new init until more time passes and a consensus is developed.

So, for now doing it all from the spec file is the way forward.

Comment 17 Jóhann B. Guðmundsson 2011-07-26 15:15:25 UTC
Hum could you clarify? 

Are you talking about from packaging perspective or systemd? ( or both )

Anway it would be good to get the problem outlined here so we can see what can be done to solve it

Comment 18 Steve Grubb 2011-07-26 15:35:43 UTC
From a packaging perspective. The initscript for sysvinit will have to be manually deleted and the new one installed in the spec file. I also do not plan to make any code changes one way or another based on what init system is being used.

Comment 19 Jóhann B. Guðmundsson 2011-07-26 17:01:16 UTC
Hum I see I have not posted the actual approved guidelines which you might be missing along with the script snippet samples 


Comment 20 Steve Grubb 2011-07-26 17:29:44 UTC
Hmm...doesn't really change my opinion. I think its a big mistake to put config information in /lib. But this bz is not the place for that discussion. If you are a proven packager, you have my permission to make the changes to the audit package specfile to install the unit file at the correct place if you wanted.

Comment 21 Jóhann B. Guðmundsson 2011-07-26 21:41:33 UTC
Created attachment 515378 [details]
Spec file patch for auditd

Comment 22 Jóhann B. Guðmundsson 2011-07-26 21:43:12 UTC
(In reply to comment #20)
> Hmm...doesn't really change my opinion. I think its a big mistake to put config
> information in /lib. But this bz is not the place for that discussion. If you
> are a proven packager, you have my permission to make the changes to the audit
> package specfile to install the unit file at the correct place if you wanted.

Provided a spec file patch for proven packager to review and commit if error free..

Comment 23 Steve Grubb 2011-07-27 00:38:39 UTC
Thank you for the patch, I applied it and pushed it through the build system:
There was a couple minor adjustments to get it to build but seems ok. I'm sure if there are problems, I'll hear about. :) Please try it out and let me know if we have to rebuild it.

Comment 24 Tom "spot" Callaway 2011-09-09 15:26:06 UTC
audit-2.1.3-2.fc16 (which is newer than 2.1.2-2, where Steve committed the change to add systemd support) is in f16 stable. Closing this bug out.

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