bob at computerisms
Aug 2, 2013, 1:00 PM
Post #16 of 22
(127 views)
Permalink
|
Hello,
> > You might be. Please look at the permissions of the parent
> > directory.
> > You might then want to make changes to those permissions and once
> > more
> > repeat your tests. Note: In a *n[iu]x system you can delete a file
> > in
> > a directory to which you can write, even if you can't write (nor even
> > read) the said file....but the directory's permissions are about what
> > users
> > (or more correctly processes with given user's permissions) can do to
> > them. When the parent directory permits both your users to write to
> > it I think you will see results from your tests that you don't
> > expect.
> >
> > > Thank you again for your time...
> >
> > I appreciate it, but we're all learning from this. :)
I can't help it, this statement just makes me happy :)
> >
>
> Well, since its /tmp, hopefully its something reasonable like 0777 or 1777, the latter is more common which means files in /tmp can only be removed by its owner (or root).
Regarding parent permissions and write access, I am aware of this
limitation. I use this to my advantage in file servers and web servers
to ensure users cannot delete or otherwise change the top level of
certain directories. and as surmised, I am running a /tmp directory
with perms 1777.
I considered the possibility that the sticky bit was preventing clamav
from deleting the socket. For example, if the socket gets created by
root, then clamav would not be able to delete it. Since clamav can
delete if permissions are correct, I do not think the sticky bit is
playing a part here.
Nonetheless I did create a directory /clamd and chmod'd it to 777 and
set the clamd.conf to make the socket in there. I then repeated the
first four tests and observed no changes - group permissions still seem
to be ignored.
> ...would suggest that
>
> FixStaleSocket (which defaults to yes)
>
> is seeing the socket as stale when clamd starts again.
>
> So, what does the socket look like after clam restarts?
In the case where the socket is removed, it gets properly recreated as
per the LocalSocket* settings in clamd.conf (srw-rw---- 1 clamav
simscan)
In the case where the socket is not removed, it simply remains with
whatever permissions it had until it is removed manually or by changing
permissions so clamav can remove it itself.
To be clear, in all of the tests I ran, when clamd did not restart
gracefully, I rm'd the socket as root from the cli so as to let clamd
start again and let clamd recreate the socket. I then changed
permissions on the socket manually to run my tests.
Digging into the FixStaleSocket setting (explicitly set to yes in my
clamd.conf), I am a bit surprised it isn't having an effect here. As I
understand it, clamd starts as root, then drops into the clamav user. I
guess it doesn't try to clear the stale socket until after it drops root
privileges.
>
> Hmm,
>
> > Permissions and ClamAntiVirus
> >
> > To get ClamAV to play nicely with simscan's permissions you have two
> > options:
> >
<snip>
> >
> > Also make sure AllowSupplementaryGroups is set in your clamd.conf file
> > so that the clamd daemon knows about the simscan group.
>
> from: http://www.qmailwiki.org/Simscan/README
I have read this site multiple times. it has lots of useful stuff on
it.
Simscan is a queue. After qmail has accepted the mail, it hands it to
simscan, which in turn stores the message in files in its own working
directory. Simscan then calls clamav to scan the files in that
directory, and then feeds them into spamassassin. Clamav is allowed
read access to Simscan's working directory via group permissions (r-x).
It then hands the message back to qmail with a pass/fail flag and
deletes the message from its working dir.
This particular snippet you quote is to do with clamav's ability to
access the files in simscan's working directory. Without those group
permissions, clamav will be denied access to simscan's working
directory. I have considered that section of that wiki very carefully,
and I do not find a way to apply that information to the clamd socket.
This seems to be the vast majority of problems when it comes to making
simscan and clamav work together. Almost every article I found when
searching something similar to "clamav simscan permissions" was a
discussion of allowing clamav into simscan's directory to scan files.
Articles on the topic of socket permissions are much less common.
The more appropriate question, at least to my mind, is what is the
effective uid/gid of the process accessing the socket. The closest
thing I have been able to find in documentation to answer that question
is "simscan calls clamav". because the suid bit is not set on the
clamscan binary, I think that the process remains owned by simscan
throughout. That is supported by the fact that simscan works when set
as user and granted rw on the socket. I think that the opposite of the
snippet from the wiki - adding simscan to the clamav group - should
effectively nullify any conflict of permissions on the socket, hence my
reasoning for having both users in each group.
>
> taking a look at one of our clamav VMs, I see
>
> srw-rw-rw- 1 clamav clamav 0 Jul 27 03:10 /var/tmp/clamd.socket=
>
> Guess that's because neither LocalSocketGroup nor LocalSocketMode are set in our config.
As I understand things, that would be correct. This also implies to me
that you do have the User set to clamav in your clamd.conf.
I have also found in example after example, as is this case here, that
people do not unset the world rw on the socket. In doing my searching,
I found this thread:
https://bugzilla.redhat.com/show_bug.cgi?id=787434
and from that, when I set my clamd.sock to 666 (owned by
clamav/simscan), the following command allows the nobody user to send a
shutdown command to clamd.
su nobody -s /bin/sh -c 'id; echo nSHUTDOWN | socat - \
UNIX-CONNECT:/tmp/clamd.socket'
In my particular case this doesn't matter so much because daemontools
will just start it up again, but I trust I don't have to explain why
that isn't the point...
Reading that thread also got me to considering that another solution to
this problem is to not put the socket in the /tmp directory, but make a
custom directory and limit access to the socket via the permissions on
that directory. This isn't such a bad idea in that I could use it to
achieve my goal, but it seems like admitting defeat. Besides, why have
the LocalSocket* settings in clamd.conf if you can't use them?
>
> Of course, the only thing that should be connecting to the socket is clamav-milter ... we then have 4 of these VMs in a pool behind our F5 where in theory anybody on campus could use it, but nothing official (what most do is list our MX's at lower priority than their MX, but their MX is firewalled so that inbound mail has to come through our MX first...)
Thank you very much for your input...
>
> Lawrence
> _______________________________________________
> Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
> http://www.clamav.net/support/ml
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
|
