From: Mike M. <mi...@ma...> - 2007-06-24 00:14:28
|
Is there a Good Way to force ownership (both user and group) on a milter socket? I see that smfi_opensocket() honors umask, but that doesn't help with the GID, and dkim-filter doesn't seem to be picking up the primary GID of its -u argument: $ id -a dkim-filter uid=128(dkim-filter) gid=128(dkim-filter) groups=128(dkim-filter) $ ls -l /var/run/dkim-filter/dkim-filter.sock srwxr-xr-x 1 dkim-filter root 0 2007-06-15 11:44 /var/run/dkim-filter/dkim-filter.sock Why this matters: Postfix apparently (quite reasonably) will happily drop all root privs after bind()ing to port 25 and before opening its connection to its milters; at least one Debian user reports being unable to connect to dkim-filter via UNIX socket as a result. Before I use a setgid bit or a chgrp in the init script, I was curious if there's a supported way to do this in libmilter (or if this is just an oversight in dkim-filter, for that matter). Thanks, -- Mike Markley <mi...@ma...> There is an order of things in this universe. - Apollo, "Who Mourns for Adonais?" stardate 3468.1 |
From: Mark M. <Mar...@ij...> - 2007-06-24 00:22:06
|
Mike, > at least one Debian user reports being unable > to connect to dkim-filter via UNIX socket as a result. Before I use > a setgid bit or a chgrp in the init script, I was curious if there's > a supported way to do this in libmilter (or if this is just an oversight > in dkim-filter, for that matter). I hope others can answer this, but an easy way out is to use an inet socket bound to a loopback interface, instead of a Unix socket. Mark |
From: Tony E. <to...@he...> - 2007-06-24 07:29:36
|
Mike Markley skrev, on 24-06-2007 02:14: > Is there a Good Way to force ownership (both user and group) on a milter > socket? I see that smfi_opensocket() honors umask, but that doesn't help > with the GID, and dkim-filter doesn't seem to be picking up the primary > GID of its -u argument: > > $ id -a dkim-filter > uid=128(dkim-filter) gid=128(dkim-filter) groups=128(dkim-filter) > $ ls -l /var/run/dkim-filter/dkim-filter.sock > srwxr-xr-x 1 dkim-filter root 0 2007-06-15 11:44 /var/run/dkim-filter/dkim-filter.sock > > Why this matters: Postfix apparently (quite reasonably) will happily > drop all root privs after bind()ing to port 25 and before opening its > connection to its milters; at least one Debian user reports being unable > to connect to dkim-filter via UNIX socket as a result. Before I use > a setgid bit or a chgrp in the init script, I was curious if there's > a supported way to do this in libmilter (or if this is just an oversight > in dkim-filter, for that matter). FWIW I run dkim-milter with Postfix 2.4 on FC6/RHEL5-related stuff on an INET socket, so here the question doesn't arise. However, I'm running the body-URI anti-spam milter milter-link (http://www.snert.com/) on my FC6 test rig, and that insists on a unix socket; Postfix has to read and write to the socket, so I included: chmod g+w /var/run/milter/$PACKAGE_NAME.socket chgrp postfix /var/run/milter/$PACKAGE_NAME.socket In my startup file. ls -l /var/run/milter: -rw-r--r-- 1 milter milter 5 Jun 24 09:01 milter-link.pid srw-rw-r-- 1 milter postfix 0 Jun 24 09:01 milter-link.socket It seems to work ... HTH, --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl |
From: SM <sm...@re...> - 2007-06-24 08:50:13
Attachments:
dkim-filter.gid.patch
|
Hi Mike, At 17:14 23-06-2007, Mike Markley wrote: >Is there a Good Way to force ownership (both user and group) on a milter >socket? I see that smfi_opensocket() honors umask, but that doesn't help >with the GID, and dkim-filter doesn't seem to be picking up the primary >GID of its -u argument: Try the attached patch. dkim-filter will pick the primary GID of its -u argument with it. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2007-06-25 20:50:57
|
On Sun, 24 Jun 2007, SM wrote: > Try the attached patch. dkim-filter will pick the primary GID of its -u > argument with it. I think that's pretty much a bullseye, except that I'd use initgroups() instead of setgroups(). Thanks! This'll be in the next version (coming shortly). -MSK |
From: Mike M. <mi...@ma...> - 2007-06-26 03:01:43
|
On Sun, Jun 24, 2007 at 01:48:23AM -0700, SM <sm...@re...> wrote: > Hi Mike, > At 17:14 23-06-2007, Mike Markley wrote: > >Is there a Good Way to force ownership (both user and group) on a milter > >socket? I see that smfi_opensocket() honors umask, but that doesn't help > >with the GID, and dkim-filter doesn't seem to be picking up the primary > >GID of its -u argument: > > Try the attached patch. dkim-filter will pick the primary GID of its > -u argument with it. Very nice! Thanks. My other question: chmod vs. umask? My primary concern with using umask to force the socket to be group-writable is that it (should) impact any other file the filter creates, including stats and debug files, but that sounds like a pretty low risk to me. Having never run a Milter under Postfix, I have no idea what best practice is (although I did note at least one vote in favor of chmod). Just seeking opinions and any pros or cons I may have missed. -- Mike Markley <mi...@ma...> Is truth not truth for all? - Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4. |
From: SM <sm...@re...> - 2007-06-26 05:26:59
|
Hi Mike, At 20:01 25-06-2007, Mike Markley wrote: >My other question: chmod vs. umask? My primary concern with using umask >to force the socket to be group-writable is that it (should) impact any >other file the filter creates, including stats and debug files, but that >sounds like a pretty low risk to me. Having never run a Milter under >Postfix, I have no idea what best practice is (although I did note at >least one vote in favor of chmod). From what I've seen for Postfix, a chmod is done on the socket so that it is group writable. If Postfix is running under a different UID, that is the only way to solve the permissions issue. The stats and debug files would only be writable by the Postfix group in any case. The risk would be low. Still, we only need dkim-milter to write to those files. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2007-06-26 06:58:20
|
On Mon, 25 Jun 2007, Mike Markley wrote: > My other question: chmod vs. umask? My primary concern with using umask > to force the socket to be group-writable is that it (should) impact any > other file the filter creates, including stats and debug files, but that > sounds like a pretty low risk to me. Having never run a Milter under > Postfix, I have no idea what best practice is (although I did note at > least one vote in favor of chmod). The socket is created using only umask by the bind() call in listener.c. The only other files created are: - temp files in libdkim, if needed because DKIM_LIBFLAGS_TMPFILES or DKIM_LIBFLAGS_KEEPFILES is set; these are created by a call to mkstemp() which (according to the man pages) forces the mode to 0600 so the umask doesn't matter - the cache database in libdkim, if _FFR_QUERY_CACHE is enabled and the cache gets big enough to require a backing store file be created; it's unclear whether the mode of this is forced to 0600 or not (I think it is), but nothing other than dkim-filter needs to access this (and I believe it's unlinked immediately on creation anyway) - the stats database in dkim-filter, which must be created with permissions such that someone running dkim-stats can read the database If we can come up with a use case in which the current implementation is insufficient, I can possibly justify a patch of some kind to libmilter. |
From: Mike M. <mi...@ma...> - 2007-06-26 08:33:22
|
On Mon, Jun 25, 2007 at 11:58:04PM -0700, Murray S. Kucherawy <ms...@se...> wrote: > The socket is created using only umask by the bind() call in listener.c. > The only other files created are: > > - temp files in libdkim, if needed because DKIM_LIBFLAGS_TMPFILES or > DKIM_LIBFLAGS_KEEPFILES is set; these are created by a call to mkstemp() > which (according to the man pages) forces the mode to 0600 so the umask > doesn't matter > > - the cache database in libdkim, if _FFR_QUERY_CACHE is enabled and the > cache gets big enough to require a backing store file be created; it's > unclear whether the mode of this is forced to 0600 or not (I think it is), > but nothing other than dkim-filter needs to access this (and I believe > it's unlinked immediately on creation anyway) > > - the stats database in dkim-filter, which must be created with > permissions such that someone running dkim-stats can read the database Okay, that's quite helpful. > If we can come up with a use case in which the current implementation is > insufficient, I can possibly justify a patch of some kind to libmilter. Just IMO, this all sounds very reasonable; I'm just picking brains to figure out how to best make a package that's usable by the most configurations with the least tweaking, since this IS intended to eventually end up in a stable release... :). Given the detail above, SM's patch + umask seems like it should do the trick nicely. (From a purely selfish perspective: I'm not building with _FFR_QUERY_CACHE, so even if that isn't forced to 0600, it's not a problem here.) -- Mike Markley <mi...@ma...> The universal thing about sysadmins is that we're lazy as hell. - Morgan McMillian |
From: Murray S. K. <ms...@se...> - 2007-06-26 16:16:24
|
On Tue, 26 Jun 2007, Mike Markley wrote: > Given the detail above, SM's patch + umask seems like it should do the > trick nicely. (From a purely selfish perspective: I'm not building with > _FFR_QUERY_CACHE, so even if that isn't forced to 0600, it's not a > problem here.) 0600 would be appropriate anyway; there's no legitimate reason for any other process to gain access to that cache. |