Socket paths

I see in the redhat/mimedefang-init.in and
redhat/mimedefang-sysconfig.in files in the source tarball
that the
sockets used to be placed under /var/run by default and are
now placed
under /var/spool/MIMEDefang.  I was curious to know why this
change
was made?

I'm trying to figure out some SELinux issues on my mail
server, and it
looks like putting the sockets back under /var/run may be
the best way
to fix those issues.  (It also looks like /var/run is more
consistent
with convention and with the LSB.)  Based on that, I was
wondering if
the default socket paths should be changed back to
/var/run.

Thank you.

Josh Kelley
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

Josh Kelley wrote:

> I see in the redhat/mimedefang-init.in and
> redhat/mimedefang-sysconfig.in files in the source
tarball that the
> sockets used to be placed under /var/run by default and
are now placed
> under /var/spool/MIMEDefang.  I was curious to know why
this change
> was made?

Because the sockets need to be in a directory that's
writable by the
"defang" user.

> I'm trying to figure out some SELinux issues on my mail
server, and it
> looks like putting the sockets back under /var/run may
be the best way
> to fix those issues.  (It also looks like /var/run is
more consistent
> with convention and with the LSB.)  Based on that, I
was wondering if
> the default socket paths should be changed back to
/var/run.

Possibly, but we are so dependent on having them in
/var/spool/MIMEDefang
that I doubt I will make that change in the mainline code.

Regards,

David.
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

On Thu, 2007-02-22 at 17:45 -0500, David F. Skoll wrote:
> Josh Kelley wrote:
> 
> > I see in the redhat/mimedefang-init.in and
> > redhat/mimedefang-sysconfig.in files in the source
tarball that the
> > sockets used to be placed under /var/run by
default and are now placed
> > under /var/spool/MIMEDefang.  I was curious to
know why this change
> > was made?
> 
> Because the sockets need to be in a directory that's
writable by the
> "defang" user.

Why's that? Couldn't the socket itself be writable by the
defang user...
or does the daemon need to unlink() it?

Richard


_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 23 Feb 2007, David F. Skoll wrote:

> The daemon needs to create the socket.  It's running as
"defang" at that
> point.

It's rather common (at least in Debian Linux) to create
directories, say 
/var/run/sendmail, chown them appropriately and chmod o=
them.

But everyone, who likes it like so, can tweak it in the
init.d script 
easily, I think.

Bye,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRd8HVugJIbZtwg6XAQLXfQf+IysmlyulGxcsAGm4dTCM7Pe7MKi5
+rxg
H0ZFmDRvBsmFotRH+FLC6ASxtljus8lLJjh+5kt3QtJKS6YF9yHHM9aiDW5M
sDON
qXV1oWyd28i7KBJU5DQKUnEhvHEoq9y81ImX+FWU8RUMjOwYHnzILXJFyyLI
QJuH
mSd1mQYEeEqo6GjuGci6lIGVstezV09pK6xYrZW0v7/rDoLXnwvD6tNlHK0q
dZVy
vImYajhEQbb3h36uT8Y+LFenMG/nkiyhx4JWwfamDehFwg/m0H1AC5avvWZH
YTC7
t1jhuVMoH+j1xbtOeN/cK594F+4W4QQaWvmLbX7Yb0ZhDV6lLIo9Ag==
=CODG
-----END PGP SIGNATURE-----
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

On 2/23/07, David F. Skoll <dfsroaringpenguin.com>
wrote:
> Still, to each his own I guess.  Back to the OP's
point:  I feel your
> pain with SELinux.  SELinux is one of those
"great-in-theory,
> horrible-in-practice" bits of software.  Given the
absurd complexity
> of setting up SELinux policies, I'm not sure that it
actually improves
> security that much.  Can you *prove* that your SELinux
policy does
> exactly what you need (and only what you need?)  A
simpler system
> like Stackguard probably buys you 95% of SELinux's
security at 5% of its
> complexity.

I guess that hasn't really been my experience with SELinux. 
I can't
*prove* that it does exactly what I need, but I figure
there's a lot
of smart folks working on it trying to see that it does, and
I know
that it provides some level of protection even if it doesn't
do
exactly what I need.  It can be a pain in the neck when it
doesn't
work, but for a lot of services, it "just works",
and it's usually not
hard to disable for the services for which it doesn't work.

I guess that's why I brought it up here; I'd like to see
MIMEDefang
made to "just work" if it's not too much trouble. 
Since Red Hat does
seem to be pushing SELinux, could MIMEDefang's redhat/*
files be
modified to put the sockets under a new defang-writable
/var/run/mimedefang directory, following Steffen Kaiser's
suggestion?

(Has anyone else run into SELinux problems with MIMEDefang?
Specifically, if I make /var/spool/MIMEDefang a tmpfs, as
the wiki
suggests, it's labeled with a tmpfs security context, and an
RPM
upgrade of MIMEDefang then fails when it tries to apply a
different
security context.  /var/spool/MIMEDefang can be mounted with
a fixed
security context to work around that, but then socket
creation doesn't
work right, hence my original question.)

Thanks.

Josh Kelley
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang