| 1 |
good morning, |
| 2 |
|
| 3 |
i would like to point out a small flaw in some packages that are currently being used in portage that can make things very complicated once the selinux policy will be used in a larger scale. |
| 4 |
|
| 5 |
the following packages: qmail-*, djbdns, relay-ctrl, serialmail, bincimap, slidentd, leafnode, fnord, publicfile, nullmailer (and possibly others in the future) all have in common the dependency to daemontools. |
| 6 |
|
| 7 |
for those who don't use daemontools, more info about it can be found here: |
| 8 |
http://cr.yp.to/daemontools.html |
| 9 |
|
| 10 |
to add a daemon to the 'supervise pool' (let's say qmail), one should make a symlink from a $SUPERVISE_DIR/qmail-smtpd to /service/qmail-smtpd. |
| 11 |
to start it, one must run svc -u qmail-smtpd, and so on. |
| 12 |
|
| 13 |
supervise will create inside $SUPERVISE_DIR/<daemon_name>/supervise/ a lock file, two fifo files and one regular file containing status information. |
| 14 |
if $SUPERVISE_DIR/<daemon_name>/log directory exists, then $SUPERVISE_DIR/<daemon_name>/log/supervise/ will have the same structure as above. |
| 15 |
|
| 16 |
all this maintenance can be very easy with sys-apps/supervise-scripts (with one condition i will explain later). |
| 17 |
|
| 18 |
my problem is that every package (at least those i've been using) has it's own $SUPERVISE_DIR. for qmail is /var/qmail/supervise/qmail-*, for djb-cache the default is /{etc,var}/dnscache, for tinydns is /{etc,var}/tinydns, for publicfile is /home/publicfile?/{ftpd,httpd} (if I remember correctly) |
| 19 |
|
| 20 |
i suggest to make a common denominator for all the packages that use daemontools: $SUPERVISE_DIR should allways be /var/service/<daemon_name>, and if the user must choose this directory at install time (as in the djbdns suite) then the default should be the same /var/service/<daemon_name>. |
| 21 |
|
| 22 |
pros: |
| 23 |
|
| 24 |
- the file_context policy for daemontools related to the supervise directories will have only 11 lines: |
| 25 |
|
| 26 |
/var/service/.* system_u:object_r:svc_svc_t |
| 27 |
/var/service/.*/down system_u:object_r:svc_down_t |
| 28 |
/var/service/.*/supervise/control system_u:object_r:svc_control_t |
| 29 |
/var/service/.*/supervise/ok system_u:object_r:svc_ok_t |
| 30 |
/var/service/.*/supervise/lock system_u:object_r:svc_lock_t |
| 31 |
/var/service/.*/supervise/status system_u:object_r:svc_status_t |
| 32 |
/var/service/.*/log/status system_u:object_r:svc_logstatus_t |
| 33 |
# environment variables |
| 34 |
/var/service/.*/env(/.*)? system_u:object_r:svc_env_t |
| 35 |
# starting scripts |
| 36 |
/var/service/.*/run.* system_u:object_r:svc_run_t |
| 37 |
/var/service/.*/log/run system_u:object_r:svc_run_t |
| 38 |
# log |
| 39 |
/var/service/.*/log/main(/.*)? system_u:object_r:svc_log_t |
| 40 |
|
| 41 |
- administration of daemons is much simpler. supervise-scripts can add and remove daemons (because he only uses /var/service as daemon repository). |
| 42 |
|
| 43 |
cons: |
| 44 |
|
| 45 |
- the file_context policy for supported daemons will be (11 * no_of_supported_daemons) |
| 46 |
- new ebuils should move the contents of $OLD_SUPERVISE_DIR to /var/service/<daemon_name> and create a link to /service/<daemon_name> |
| 47 |
|
| 48 |
what do you think about this? |
| 49 |
|
| 50 |
i'm sorry to tell you, but the policies that i've sent to buzilla assume the /var/service/<daemon_name> location. i've never used the funny locations packages want to install $SUPERVISE_DIR in. imagine having /etc/init.d/apache in /home/apache, /etc/init.d/squid in /var/lib/squid. |
| 51 |
|
| 52 |
the policies can be made to comply with the current $SUPERVISE_DIR locations, but i will not reply to funny questions regarding the number of file_contexts in my rules :) |
| 53 |
|
| 54 |
bye, |
| 55 |
peter |
Archives