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
