Hi,
http://bugs.debian.org/394779
I retract my previous comment on this bug. I was confused.
I think what Josip mentions initially on this bus gives good starting
point. Since the courier package has not change since then, reasonable
thing to do is document the best practice to work around the
courier-authdaemon package incompatibility.
Let's recap by commenting on Josip's points:
> Sounds like you may want to:
> * make maildrop setgid daemon, although I don't reckon that would work
> well if you still need to setgid mail (in order to lock files in
> /var/mail). Do you need that?
Clearly, Josip does not want to do this. I agree.
> Also, other repercussions of making a binary setgid daemon may exist.
> * change permissions of those files to be mail:mail
Since we are making get GID mail for maildrop, this could be either
mail:mail or daemon:mail 775
> * ask the maintainer or courier-authdaemon and courier-maildrop what's
> * their strategy with this whole daemon user thing :)
This failed so far, thus I am proposing other route :-)
> * handle upgrades by dpkg-divert'ing /usr/bin/maildrop and making a note
> somewhere always to check whether you need the new one, but that's an
> ugly workaround which may fail later
Let's not take risky route.
Before going further, let's review the solution Julien posted.
dpkg-statoverride --add daemon mail 0750 /var/run/courier/authdaemon
Really? As I read courier-authdaemon init script, the /var/run/courier
and /var/run/courier/authdaemon directories are generated by init script
daemon:daemon with 775. So what does it do to run this command? This
is meant to be used for package installed files. This looks odd for me.
But Julien may have found some true secret ... I experimented:
$ sudo ls -la /var/run/courier
total 0
drwxrwxr-x 3 daemon daemon 60 Feb 24 21:23 .
drwxr-xr-x 27 root root 1040 Feb 24 21:34 ..
drwxr-x--- 2 daemon daemon 100 Feb 24 21:23 authdaemon
$ sudo dpkg-statoverride --add daemon mail 0750 /var/run/courier/authdaemon
$ sudo ls -la /var/run/courier
total 0
drwxrwxr-x 3 daemon daemon 60 Feb 24 21:23 .
drwxr-xr-x 27 root root 1040 Feb 24 21:34 ..
drwxr-x--- 2 daemon daemon 100 Feb 24 21:23 authdaemon
... reboot just to be sure ...
$ sudo ls -la /var/run/courier
total 0
drwxrwxr-x 3 daemon daemon 60 Feb 25 01:49 .
drwxr-xr-x 27 root root 1040 Feb 25 01:49 ..
drwxr-x--- 2 daemon daemon 100 Feb 25 01:49 authdaemon
So at least what Julien says does not work now.
===================================================
My solution is the following.
Since modification on the conffile is OK, I would do:
$ diff -u courier-authdaemon.orig courier-authdaemon
--- courier-authdaemon.orig 2012-02-25 01:53:48.141475900 +0900
+++ courier-authdaemon 2012-02-25 01:55:07.337868715 +0900
@@ -30,11 +30,11 @@
log_daemon_msg "Starting Courier authentication services" "authdaemond"
if [ ! -d "$rundir_courier" ]; then
mkdir -m 0775 $rundir_courier
- chown daemon:daemon $rundir_courier
+ chown daemon:mail $rundir_courier
fi
if [ ! -d "$rundir" ]; then
mkdir -m 0750 $rundir
- chown daemon:daemon $rundir
+ chown daemon:mail $rundir
fi
$daemonscript start
log_end_msg 0
If you do not reboot, you need to change permission of these existing
directories. This is theoretical solution for me. I am not using this
functionality though. Thus if I really need to do mail:mail as Josip
mentioned is not experimented but both seem good enough for me.
I think this is best practice solution for current situation.
It would be nice if courier-authdaemon package update its init script to
make this configurable via /etc/default/courier-authdaemon.
Regards,
Osamu
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
