On Thu, 20 Mar 2003, Dave Sill wrote:
> Ed Phillips <[EMAIL PROTECTED]> writes:
>
> > On Thu, 20 Mar 2003, Dave Sill wrote:
> >
> > > This is pretty important limitation to using clamd/clamdscan. Is it
> > > documented?
> >
> > Sure... run "man intro" on most any Unix system and read the part about
> > permissions, uids, etc., ... ;-)
>
> Very funny, Ed. I was referring to the fact that clamscan and
> clamdscan behave differently because clamd has to have access to the
> file, not just clamdscan.
Ahhhh... that wasn't clear to me. Sorry.
clamdscan is not clamscan at all, it's just a simple program that tells
clamd what to scan, using the protocol that is required to talk to clamd.
It's not obvious at first glance. Whenever you use clamd, it does the
actual scanning of the files... and that's the way you want it because the
whole point of clamd is to avoid the virus database load for scanning
individual files.
> > Of course, for a process to be able to read ANY file on a Unix system the
> > process needs to be running with uid 0, or the files themselves need to
> > have proper permissions set. There's not really anything ClamAV can do to
> > change these simple facts. Did you think clamd would somehow be able to
> > bypass normal Unix file permissions? What would you like clamd to do
> > exactly?
>
> Well, I guess I thought clamdscan sent the file to clamd. Obviously I
> was wrong.
It wasn't clear you thought that. You could certainly make a program that
that can receive files through a tcp/unix socket, save them
temporarily, and tell clamd to scan the temp files, and sent back the
results from clamd. But, it's probably easier to just solve the
permissions problem without trying to run clamd as root.
> > In our setup, we use sendmail + MIMEDefang + clamd. When the email
> > messages/attachments are broken out by MD to be scanned, they are owned by
> > the user that MIMEDefang runs as (in our case, "defang"). So, we just
> > make clamd run as "defang" so it can scan the mail files.
>
> Yes, that's exactly what I suggested in my message. The problem with
> that is that clamdscan then only works right for scanning files that
> that user has access to.
Of course, and my point was that these aspects are typical Unix caveats,
and have nothing to do with a problem in the design or documentation of
ClamAV. clamdscan is a new part of ClamAV. The docs were pretty lacking
last time I checked... especially in the "what the heck is this intended
to be used for, pragmatically speaking" sense. I think most of the docs
for ClamAV are pretty clear though, regarding how to run it and
permissions and the "clamav" user and groups, etc.
I get the impression from the messages emitted by the "configure" script
and "Example" keyword in the configuration file that Tomasz is pretty worn
out with people running into permissions and simple Unix issues... ;-)
> If someone thinks clamdscan works just like clamscan[1], he probably
> won't expect clamd to silently skip files it can't access.
IMO, it's a bug to silently skip errors. But it's not clear that the
default behavior should be the same for clamdscan/clamd and clamscan. My
preference would be for, at minimum, clamdscan/clamd report errors for any
files asked to be scanned that are inaccessible (I forget whether clamd
will scan directory trees recursively, but I don't think it does) since
you typically give clamd a full path to a file to scan - if it's not there
or there's some error, I want to be able to detect it. For clamscan, I
think it should have a flag which says whether or not to ignore
inaccessible files, report errors, etc., and it may already have this - I
just don't really use clamscan much.
> -Dave
>
> Footnotes:
> [1] s/clamscan/clamdscan/ sound familiar?
Yep... I silently ignored that message thinking "Why would someone want to
try to do that? They'll figure it out..." ;-)
Hope there was something helpful in my responses...
Ed
Ed Phillips <[EMAIL PROTECTED]> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l [EMAIL PROTECTED] for PGP public key
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
