Bug 787434 - Clamav does not create /var/run/clamd.scan/ with correct permissions
Summary: Clamav does not create /var/run/clamd.scan/ with correct permissions
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: clamav
Version: 28
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Sergio Monteiro Basto
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
: 1284253 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-05 03:21 UTC by Philip Prindeville
Modified: 2019-04-16 19:47 UTC (History)
13 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-08-07 01:16:02 UTC


Attachments (Terms of Use)
Fix socket and directory permissions (1.17 KB, patch)
2012-02-06 18:31 UTC, Philip Prindeville
no flags Details | Diff
Add clamav+mimedefang integration subpackage (4.17 KB, patch)
2012-02-29 20:40 UTC, Philip Prindeville
philipp: review? (rh-bugzilla)
Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 754555 None CLOSED clamav-update does not create freshclam.log with correct permissions 2019-05-01 03:28 UTC

Internal Trackers: 754555

Description Philip Prindeville 2012-02-05 03:21:55 UTC
Description of problem:

There's no point in having a LocalSocketGroup option in scan.conf to allow giving away the socket if the socket itself resides in an unreadable/unsearchable directory:

[root@mail mail]# grep '^LocalSocketGroup' /etc/clamd.d/scan.conf
LocalSocketGroup defang
[root@mail mail]# ls -ld /var/run/clamd.scan
drwx--x---. 2 clamscan clamscan 80 Jan 24 22:24 /var/run/clamd.scan
[root@mail mail]# ls -l /var/run/clamd.scan/clamd.sock
srw-rw----. 1 clamscan defang 0 Jan 24 22:24 /var/run/clamd.scan/clamd.sock [root@mail mail]#


The permissions of /var/run/clamd.scan/ need to be 755 or 751.

This problem was indicated when clamav-0.97.3-1601.fc16 was submitted for testing, but that was released despite this important flaw.

I'm hoping that the maintainer will be more diligent in the future.


Version-Release number of selected component (if applicable):

clamav-0.97.3-1601.fc16

How reproducible:

As above.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Enrico Scholz 2012-02-05 10:45:30 UTC
not a bug; make the users which are allowed to use the clamav scanner service a member of the 'clamscan' group or use (suggested) a tcp socket and filter by '-m owner' iptable rules.

Comment 2 Philip Prindeville 2012-02-05 19:23:49 UTC
(In reply to comment #1)
> not a bug; make the users which are allowed to use the clamav scanner service a
> member of the 'clamscan' group or use (suggested) a tcp socket and filter by
> '-m owner' iptable rules.

Except that:

(1) if you're running multiple Anti-Virus agents that are being used by the same clients (MTA's, MUA's, etc) they would *all* need to be in the clamscan group.
(2) using a TCP socket wouldn't as easily allow for SElinux coverage rule inclusion for access to the AV service.
(3) you'd need to patch clamav to remove the LocalSocketGroup directive if it isn't supported.

Comment 3 Philip Prindeville 2012-02-05 19:47:29 UTC
And let's be real here: we're talking about a trivial 1-line change:

 cat << EOF > $RPM_BUILD_ROOT%_sysconfdir/tmpfiles.d/clamd.scan.conf
-d %scanstatedir 0710 %scanuser %scanuser
+d %scanstatedir 0750 %scanuser %scanuser
 EOF

Comment 4 Philip Prindeville 2012-02-05 20:10:40 UTC
Errr, correct... actually:

d %scanstatedir 0751 %scanuser %scanuser

so that other groups can search the directory.

Comment 5 Enrico Scholz 2012-02-05 23:17:03 UTC
> (1) if you're running multiple Anti-Virus agents that are being used by the
> same clients (MTA's, MUA's, etc) they would *all* need to be in the clamscan
> group.

clamd@scan is a service for users within the 'clamscan' group.


> (2) using a TCP socket wouldn't as easily allow for SElinux coverage rule
> inclusion for access to the AV service.

I am not aware of a non-trivial system which works without local SELinux adaptations. So, one ore two rules more won't be a problem.


> (3) you'd need to patch clamav to remove the LocalSocketGroup directive if it
> isn't supported.

??? clamav-milter (which uses clamd@scan) works fine here without such a patch.


> +d %scanstatedir 0750 %scanuser %scanuser

will provide an insecure setup because socket is world writable

Comment 6 Philip Prindeville 2012-02-06 00:39:45 UTC
(In reply to comment #5)
> > +d %scanstatedir 0750 %scanuser %scanuser
> 
> will provide an insecure setup because socket is world writable

Then fix the root cause!

 # Sets the permissions on the unix socket to the specified mode.
 # Default: disabled (socket is world accessible)
-#LocalSocketMode 660
+LocalSocketMode 660

If the vulnerability is in the SOCKET's permissions then fix that. Not the directory that contains it.

Comment 7 Enrico Scholz 2012-02-06 08:46:56 UTC
sorry, won't happen. That's not the way how clamav-scanner is supposed to work.

Comment 8 Philip Prindeville 2012-02-06 17:27:27 UTC
(In reply to comment #7)
> sorry, won't happen. That's not the way how clamav-scanner is supposed to work.

It's the way clamav is supposed to work or it wouldn't have both the LocalSocketMode and LocalSocketGroup configuration options.

What purpose does not handling these options correctly serve?

Comment 9 Philip Prindeville 2012-02-06 18:31:42 UTC
Created attachment 559717 [details]
Fix socket and directory permissions

This is a trivial fix to enforce the socket permissions on the socket itself and not on the directory.

Can you please explain what the down side of this fix is?

Comment 10 Daniel Walsh 2012-02-06 19:09:45 UTC
What SELinux issues are you seeing?

Comment 11 Daniel Walsh 2012-02-06 20:24:09 UTC
I have been talking to Phillip about this problem in IRC.  And I guess the fundemental problem here is you are program mimedefang running as the defang user, and it wants to tell clamscan (clamscan user) to scan files it owns.

In all cases he has to add the clamscan user to the defang group if it is going to read files that are not world readable.

Option 1 on clamscan would be to allow access to the world writable socket and change the permissions on the directory to 751 and the socket to 666.

Option 2 would be to also add defang to the clamscan group and run the clamscan socket as 660 and the directory as 750 and owned by the clamscan group.

Option 3 would be to run clamscan with the defang group and allow change the protection to 751 since the directory would still be owned by the clamscan group.

I don't like option 3 since, if I had a third user that wanted access to clamscan I would have to add him to the defang group.

Option 2 could be a problem if clamscan had a group writable directory or content available to the group that we did not want defang reading.

Option 1 could be a problem if we were concerned about random users convincing clamscan to read content that we could cause it to be corrupted or if the clamscan socket code had bugs in it.

Comment 12 Philip Prindeville 2012-02-06 21:06:54 UTC
With Option 2, if the user changes the configuration line to:

LocalSocketGroup xxx

that group would still not be able to open the socket, as the socket would live in a directory that was o-rwx to other (i.e. to members of group 'xxx').

This violates the principle of least astonishment.

I think that whatever option we go with, having the directory be 751 makes the most sense.

Option 2 is a concern because if mimedefang were ever subverted, it could potentially write to any g+w files that clamscan owned (i.e. AV dictionaries, etc).

Worth noting that the socket currently is created as mode 666 in Option 1. That's cause for concern.

Comment 13 Enrico Scholz 2012-02-07 14:02:22 UTC
clamav-scanner is a streaming only instance of 'clamd' and is more or less for demonstration purposes only. It has no special permissions (e.g. for reading MIMEDefang files) and the 'clamscan' user has minimal privileges (e.g. it has no (writable) home dir nor does it own files except the communication sockets).

Sharing a clamd instance between multiple services (e.g. MIMEDefang and a web proxy) is risky, because e.g. the proxy service could initiate a scan of private defang files.  Or, the defang service could DOS the proxy by 'echo nSHUTDOWN > /var/run/clamd.scan/scan.sock'.

When you want a 'clamd' instance with more privileges, create such an instance.

When you need only a streaming clamd scanner (which is not the case for defang) and do not want to add users to the 'clamscan' group, you can change ACLs of the socket dir. E.g. (untested)

 [Unit]
 After = tmpfiles.service
 Before = clamd@scan.service
 Before = my-special.service

 [Service]
 Type = oneshot
 Exec = setfacl -m u:my-user:x /var/run/clamd.scan

Comment 14 Philip Prindeville 2012-02-07 18:12:48 UTC
(In reply to comment #13)
> clamav-scanner is a streaming only instance of 'clamd' and is more or less for
> demonstration purposes only. It has no special permissions (e.g. for reading
> MIMEDefang files) and the 'clamscan' user has minimal privileges (e.g. it has
> no (writable) home dir nor does it own files except the communication sockets).

Any AV software to work with MIMEDefang has to be in the MIMEDefang group,
or else MIMEDefang would have to run wide-open. There is nothing particular
to clamav about that.

> Sharing a clamd instance between multiple services (e.g. MIMEDefang and a web
> proxy) is risky, because e.g. the proxy service could initiate a scan of
> private defang files.  Or, the defang service could DOS the proxy by 'echo
> nSHUTDOWN > /var/run/clamd.scan/scan.sock'.

So because sharing between multiple services is risky, you're going to
stop clamav-scanner from running with MIMEDefang unshared?  I don't get
this logic.

> When you want a 'clamd' instance with more privileges, create such an instance.
> 
> When you need only a streaming clamd scanner (which is not the case for defang)
> and do not want to add users to the 'clamscan' group, you can change ACLs of
> the socket dir. E.g. (untested)

I don't need to add users to the clamscan group: I only need to add the
clamscan user to the defang group... if you set the permissions on
/var/run/clamd.scan/ correctly.

>  [Unit]
>  After = tmpfiles.service
>  Before = clamd@scan.service
>  Before = my-special.service
> 
>  [Service]
>  Type = oneshot
>  Exec = setfacl -m u:my-user:x /var/run/clamd.scan

But you've still not answered my very simple question:

Why exactly isn't having the directory /var/run/clamd.scan/ be 751 and
the socket /var/run/clamd.scan/clamd.sock be 066 *not* the right thing
to do?

For that matter, why is having LocalSocketMode not work as it's supposed
to *not* a regression?

Comment 15 Philip Prindeville 2012-02-07 18:13:20 UTC
That should be "0660" of course above... sigh.

Comment 16 Philip Prindeville 2012-02-10 20:18:22 UTC
This wasn't rhetorical:

> But you've still not answered my very simple question:
> 
> Why exactly isn't having the directory /var/run/clamd.scan/ be 751 and
> the socket /var/run/clamd.scan/clamd.sock be 0660 *not* the right thing
> to do?
> 
> For that matter, why is having LocalSocketMode not work as it's supposed
> to *not* a regression?

Comment 17 Enrico Scholz 2012-02-15 22:01:16 UTC
> Why exactly isn't having the directory /var/run/clamd.scan/ be 751 and
> the socket /var/run/clamd.scan/clamd.sock be 066 *not* the right thing
> to do?

Changing directory mode to 0751 will render existing installations insecure. Patching clamd to set more restrictive default socket permissions will break existing installations which expect a world-writable file mode.

clamd@scan is for members of the clamscan group; generally, clamd instances should not be shared between several servers.  When you want clamav services for MIMEDefang, create an integration package which ships a dedicated clamd@defang instance.


> For that matter, why is having LocalSocketMode not work as it's supposed
> to *not* a regression?

Although it might be possible to configure clamd@scan in the way described by you, this encourages an insecure setup by giving a shared clamd instance more permissions.  I see only a very small gain in it and because of its effect on existing installations, I do not want to support it by the package.

Comment 18 Philip Prindeville 2012-02-15 22:34:31 UTC
(In reply to comment #17)
> > Why exactly isn't having the directory /var/run/clamd.scan/ be 751 and
> > the socket /var/run/clamd.scan/clamd.sock be 066 *not* the right thing
> > to do?
> 
> Changing directory mode to 0751 will render existing installations insecure.

'Insecure' how exactly? What's the vulnerability in detail please?

> Patching clamd to set more restrictive default socket permissions will break
> existing installations which expect a world-writable file mode.

How can they open the socket much less write to it if they don't have access to the directory? This doesn't make any sense.

And patching it how? There's no patching of the actual source required. Just changing the file directory attributes in the .rpm packaging itself.

> clamd@scan is for members of the clamscan group; generally, clamd instances
> should not be shared between several servers.  When you want clamav services
> for MIMEDefang, create an integration package which ships a dedicated
> clamd@defang instance.

It's not a question that it can't be shared between 'several servers'. It can't even be made to run with a single other service (mimedefang) in this case because of the overly restrictive permissions on the directory.

> > For that matter, why is having LocalSocketMode not work as it's supposed
> > to *not* a regression?
> 
> Although it might be possible to configure clamd@scan in the way described by
> you, this encourages an insecure setup by giving a shared clamd instance more
> permissions.  I see only a very small gain in it and because of its effect on
> existing installations, I do not want to support it by the package.

How about this? Why don't you actually *try* my patch and then tell me what specific problems/vulnerabilities it has?  It's a 3-line patch.

What 'more permissions' are you talking about?

clamav-milter uses /var/run/clamav-milter/ for it's socket's directory, and clamav-scanner uses /var/run/clamd.scan/ for it's socket's directory.

Changing the permissions on JUST the latter, /var/run/clamd.scan/ would not affect *any other instances* of clamav.

This is what my patch does. This is what I've said repeatedly my patch does.

And you'd know this if you had tried to apply it and test it before dismissing it.

The various instances of clamav should *all* be compartmentalized by having different subdirectories in /var/run/ ...

Comment 19 Philip Prindeville 2012-02-15 22:36:45 UTC
(In reply to comment #9)
> Created attachment 559717 [details]
> Fix socket and directory permissions
> 
> This is a trivial fix to enforce the socket permissions on the socket itself
> and not on the directory.
> 
> Can you please explain what the down side of this fix is?

2nd request: can I please get a code review of this patch to find out what specifically is wrong with it?  It's 3 lines of changes.

Comment 20 Enrico Scholz 2012-02-16 00:57:46 UTC
> 'Insecure' how exactly? What's the vulnerability in detail please?

# service clamd@scan restart
Redirecting to /bin/systemctl  restart clamd@scan.service
# pidof clamd
9662

# chmod 0751 /run/clamd.scan  (emulating the requested change)

# su nobody -s /bin/sh -c 'id; echo nSHUTDOWN | nc -U /run/clamd.scan/clamd.sock'
uid=99(nobody) gid=99(nobody) Gruppen=99(nobody) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

# pidof clamd
#

Comment 21 Philip Prindeville 2012-02-16 01:18:38 UTC
(In reply to comment #20)
> > 'Insecure' how exactly? What's the vulnerability in detail please?
> 
> # service clamd@scan restart
> Redirecting to /bin/systemctl  restart clamd@scan.service
> # pidof clamd
> 9662
> 
> # chmod 0751 /run/clamd.scan  (emulating the requested change)
> 
> # su nobody -s /bin/sh -c 'id; echo nSHUTDOWN | nc -U
> /run/clamd.scan/clamd.sock'
> uid=99(nobody) gid=99(nobody) Gruppen=99(nobody)
> Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> 
> # pidof clamd
> #


Which is exactly why my patch ALSO contains a line to uncomment the line:

#LocalSocketMode 0660

so that the socket gets opened as 0660. Why are you going out of your way to avoid the specifics of my patch????

Comment 22 Philip Prindeville 2012-02-16 01:20:33 UTC
I even said in comments 14-16 that the socket should be configured as 0660 specifically to mitigate this exact problem.

Comment 23 Enrico Scholz 2012-02-16 08:49:43 UTC
> Which is exactly why my patch ALSO contains a line to uncomment the line:

your patch changes the packed configuration file. I does not have any effect (except the creation of a clamd.d/scan.conf.rpmnew file) on existing installations (which have by default '#LocalSocketMode' meaning 0666)

And before you ask: doing stupid things like patching scan.conf in %post or %trigger is a no-go because it is non-working (cfg might come from cfengine or so, might use some kind of include feature) and dangerous (as admin, I do not want silent configuration changes).

Comment 24 Philip Prindeville 2012-02-17 02:34:15 UTC
So on a new install, set the directory permissions (via tmpfiles.d) to be 751, and the socket 0660, and on an existing install warn the user...(In reply to comment #23)
> > Which is exactly why my patch ALSO contains a line to uncomment the line:
> 
> your patch changes the packed configuration file. I does not have any effect
> (except the creation of a clamd.d/scan.conf.rpmnew file) on existing
> installations (which have by default '#LocalSocketMode' meaning 0666)
> 
> And before you ask: doing stupid things like patching scan.conf in %post or
> %trigger is a no-go because it is non-working (cfg might come from cfengine or
> so, might use some kind of include feature) and dangerous (as admin, I do not
> want silent configuration changes).

So on a new install, set the directory permissions (via tmpfiles.d) to be 751, and the socket 0660, and on an existing install warn the user...

Anyway, whenever security vulnerabilities are found with file permissions, this problem has come up in the past--and it hasn't been an impediment to having future installs resolve the vulnerability.

Comment 25 Philip Prindeville 2012-02-21 20:58:30 UTC
As a side note, the /usr/share/doc/clamav-server-0.9.73/README is wrong.

Or else the /usr/share/clamav/clamd-wrapper is.

Either the README is skipping the step where you need to create:

# echo "d /var/run/clamd.<SERVICE> 0710 <USER> clamscan" > /etc/tmpfiles.d/clamd.<SERVICE>.conf

but after emulating these steps by hand (or else rebooting), you still need:

# chcon -t clamd_var_run_t /var/run/clamd.<SERVICE>

The other possibility is that the clamd-wrapper script is wrong and it needs to do:

CLAMD_DIR=`dirname $CLAMD_PIDFILE`
[ -d $CLAMD_DIR ] || {
  mkdir $CLAMD_DIR
  chmod 0710 $CLAMD_DIR
  XUSER=`awk '/^User / {print $2; } | tail -1'`
  : ${XUSER:=clamscan}
  chown $XUSER.clamscan $CLAMD_DIR
  chcon -t clamd_var_run_t $CLAMD_DIR
}

and hope that's correct...

Also, the steps that describe creating /etc/init.d/clamd.<SERVICE>

don't mention how to stop the init scripts from redirecting to systemctl and failing.

I found I had to put:

SYSTEMCTL_SKIP_REDIRECT=1

into /etc/init.d/clamd.<SERVICE> as the first executable line. There might be an easier way to do this, but I don't know it.

Comment 26 Philip Prindeville 2012-02-22 19:49:42 UTC
Also, the clamd.init script (once copied over and after the 'chkconfig'), you also need to run:

% restorecon -R -v /etc/rc.d

after the chkconfig or SElinux will block the client from connecting to the clamd socket.

Comment 27 Philip Prindeville 2012-02-27 22:16:03 UTC
Also, did the Fedora community do away with attaching patches as diffs so they could be discussed first before being committed?

Because I find the new contents of README-clamd to be less than useful:

clamd@<SERVICE>.service: (systemd instance)
  * instance of clamd@.service

where does this file go? What's in it? What does it come from?

Also, the latest README removes references to clamd.init and clamd.sysconfig, 
but clamd.SERVICE.init and clamd.sysconfig are still present in the source tree and in the clamav.spec file.

Comment 28 Philip Prindeville 2012-02-28 02:42:11 UTC
Looking at git a bit more, it seems that the file:

/lib/systemd/system/clamd@.service

will eventually by part of the package, and what will need to be done is:

% ln -sf clamd@.service /lib/systemd/system/clamd@<SERVICE>.service
% systemctl --system daemon-reload
% systemctl enable clamd@<SERVICE>.service
% systemctl start clamd@<SERVICE>.service

to enable and start the service.

Please update the README to include these steps.

Comment 29 Philip Prindeville 2012-02-28 02:45:30 UTC
Looking at the .spec file, I see:

! test -x /sbin/restorecon || /sbin/restorecon %freshclamlog

for what it's worth, a lot of people use the shorthand:

[ ! -x /sbin/restorecon ] || /sbin/restorecon %freshclamlog

and find that a lot more readable, or better yet:

[ -x /sbin/restorecon ] && /sbin/restorecon %freshclamlog

which is more to the point since it makes it clear that the 2nd part is only to be done if the first part is true, as opposed to doing the 2nd part only when the first part fails.

Comment 30 Philip Prindeville 2012-02-29 20:40:55 UTC
Created attachment 566640 [details]
Add clamav+mimedefang integration subpackage

As comment #17 recommends.

Comment 31 Enrico Scholz 2012-03-01 19:40:50 UTC
as explained in #754276 I do not want to ship such integration packages within clamav itself (nor do I request that this is done by the exim, defang, amavisd, ... packages).

A separate package written by somebody who knows both clamav and the other program is a more clean solution.

Regarding you scriptlets:

| [ -x /sbin/restorecon ] && /sbin/restorecon %freshclamlog

is wrong because expression fails (and might abort the rpm %scriptlet) when /sbin/restorecon does not exist.


Generally, there is not needed a 'clamd@<SERVICE>.service' file or link. It is sufficient to create 'After = clamd@<SERVICE>.service' and/or similar entries in the unitfile of the other program.  But these are generic systemd setup steps which are explained more detailed by the systemd documentation.

The SysV stuff (inclusive the clamd-wrapper) is going to die in the midterm (RHEL5 EOL is the target date) and will see only fixes for really critical bugs. 

Thanks for pointing to SYSTEMCTL_SKIP_REDIRECT=1; I will check what's going on there.

Comment 32 Philip Prindeville 2012-03-02 21:43:05 UTC
(In reply to comment #31)
> as explained in #754276 I do not want to ship such integration packages within
> clamav itself (nor do I request that this is done by the exim, defang, amavisd,
> ... packages).
> 
> A separate package written by somebody who knows both clamav and the other
> program is a more clean solution.

Except that not updating the integration package's file when the file it's derived from (i.e. what's packaged in clamav) would lead to it quickly getting out of date.

If changes happen in clamav (say default settings change, the SElinux context changes, etc) then all that needs to be reflected in the integration package as well.

They are too closely coupled to not be done as a subpackage one from the other.

> Regarding you scriptlets:
> 
> | [ -x /sbin/restorecon ] && /sbin/restorecon %freshclamlog
> 
> is wrong because expression fails (and might abort the rpm %scriptlet) when
> /sbin/restorecon does not exist.

Ah, yes. To make sure the expression exits with truth, you'd need:

[ ! -x /sbin/restorecon ] || /sbin/restorecon %freshclamlog


> Generally, there is not needed a 'clamd@<SERVICE>.service' file or link. It is
> sufficient to create 'After = clamd@<SERVICE>.service' and/or similar entries
> in the unitfile of the other program.  But these are generic systemd setup
> steps which are explained more detailed by the systemd documentation.
> 
> The SysV stuff (inclusive the clamd-wrapper) is going to die in the midterm
> (RHEL5 EOL is the target date) and will see only fixes for really critical
> bugs. 
> 
> Thanks for pointing to SYSTEMCTL_SKIP_REDIRECT=1; I will check what's going on
> there.

Did you also see the change in my patch to the system .service file to indicate the PIDFile?

Comment 33 Enrico Scholz 2012-03-03 10:30:21 UTC
I do not see a reason to use PIDFile with systemd; pidfiles are a hack from old SysV init days. Managing them causes lot of trouble and every modern init system works well without them.

Comment 34 Fedora End Of Life 2013-01-16 22:40:49 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 35 Sergio Monteiro Basto 2013-02-11 12:31:18 UTC
I have to run clamfix.sh , every reboot on F16.

cat clamfix.sh 
mkdir /var/run/clamd.clamd
chown qscand:qscand /var/run/clamd.clamd

Comment 36 Fedora End Of Life 2013-02-14 01:13:13 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 37 Sergio Monteiro Basto 2013-02-18 20:58:50 UTC
(In reply to comment #33)
> I do not see a reason to use PIDFile with systemd; pidfiles are a hack from
> old SysV init days. Managing them causes lot of trouble and every modern
> init system works well without them.
 
Correct.

but you need add :

[Install]
WantedBy=multi-user.target

to may enable it and start it on boot 

also seems need set to run before spamassassin .

Comment 38 Fedora Admin XMLRPC Client 2013-02-27 21:05:48 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 39 Stefan Gies 2013-05-21 08:34:54 UTC
10:19:40 : Heruntergeladen: (1/14): clamav-0.97.8-1.fc18.x86_64.rpm ( 922 k )
10:19:46 : Heruntergeladen: (2/14): clamav-data-0.97.8-1.fc18.noarch.rpm ( 58 M )
10:19:46 : Heruntergeladen: (3/14): clamav-devel-0.97.8-1.fc18.x86_64.rpm ( 30 k )
10:19:46 : Heruntergeladen: (4/14): clamav-filesystem-0.97.8-1.fc18.noarch.rpm ( 17 k )
10:19:46 : Heruntergeladen: (5/14): clamav-lib-0.97.8-1.fc18.x86_64.rpm ( 3.6 M )
10:19:46 : Heruntergeladen: (6/14): clamav-milter-0.97.8-1.fc18.x86_64.rpm ( 85 k )
10:19:46 : Heruntergeladen: (7/14): clamav-milter-systemd-0.97.8-1.fc18.noarch.rpm ( 17 k )
10:19:46 : Heruntergeladen: (8/14): clamav-scanner-0.97.8-1.fc18.noarch.rpm ( 23 k )
10:19:46 : Heruntergeladen: (9/14): clamav-scanner-systemd-0.97.8-1.fc18.noarch.rpm ( 17 k )
10:19:46 : Heruntergeladen: (10/14): clamav-server-0.97.8-1.fc18.x86_64.rpm ( 92 k )
10:19:47 : Heruntergeladen: (11/14): clamav-server-systemd-0.97.8-1.fc18.noarch.rpm ( 17 k )
10:19:47 : Heruntergeladen: (12/14): clamav-update-0.97.8-1.fc18.x86_64.rpm ( 83 k )
10:19:47 : Heruntergeladen: (13/14): clamsmtp-1.10-10.fc18.x86_64.rpm ( 44 k )
10:19:47 : Heruntergeladen: (14/14): sendmail-milter-8.14.7-1.fc18.x86_64.rpm ( 69 k )
10:19:47 : YUM: Running Transaction Check
10:19:47 : YUM: --> Fülle Verarbeitungsset mit ausgewählten Paketen. Bitte warten.
10:19:47 : YUM: ---> Paket clamav-lib.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-scanner.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-update.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-server.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-milter-systemd.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-devel.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-server-systemd.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-milter.x86_64 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-data.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamav-filesystem.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket clamsmtp.x86_64 0:1.10-10.fc18 markiert, um an update zu werden
10:19:47 : YUM: ---> Paket sendmail-milter.x86_64 0:8.14.7-1.fc18 markiert, um an update zu werden
I grab from yumex the error messages:


10:19:47 : YUM: ---> Paket clamav-scanner-systemd.noarch 0:0.97.8-1.fc18 markiert, um an update zu werden
10:19:47 : RPM Scriptlet: Aufruf: groupadd [Optionen] GRUPPE
10:19:47 : YUM: Optionen:
10:19:47 : YUM:   -f, --force                   Ohne Fehler beenden, falls die Gruppe
10:19:47 : YUM:                                 bereits existiert
10:19:47 : YUM:                                 und Operation für -g abbrechen, falls die
10:19:47 : YUM:                                 GID bereits verwendet wird
10:19:47 : YUM:   -g, --gid GID                 GID für die neue Gruppe benutzen
10:19:47 : YUM:   -h, --help                    Diese Hilfe anzeigen, sonst nichts
10:19:47 : YUM:   -K, --key SCHLÜSSEL=WERT      Die Vorgabewerte in /etc/login.defs
10:19:47 : YUM:                                 überschreiben
10:19:47 : YUM:   -o, --non-unique              Erstellen einer Gruppe mit nicht
10:19:47 : YUM:                                 einmaliger (doppelter) GID erlauben
10:19:47 : YUM:   -p, --password PASSWORT       Dieses verschlüsselte PASSWORT für die
10:19:47 : YUM:                                 neue Gruppe verwenden
10:19:47 : YUM:   -r, --system                  Eine Systemgruppe erstellen
10:19:47 : YUM:   -R, --root CHROOT_VERZ        Verzeichnis für chroot
10:19:47 : YUM: useradd: Gruppe »clamupdate« existiert nicht.
10:19:47 : clamav-filesystem-0.97.8-1.fc18.noarch ist installiert
10:19:48 : RPM Scriptlet: warning: user clamupdate does not exist - using root
10:19:48 : YUM: warning: group clamupdate does not exist - using root
10:19:49 : clamav-data-0.97.8-1.fc18.noarch ist installiert
10:19:49 : RPM Scriptlet: warning: user clamupdate does not exist - using root
10:19:49 : YUM: warning: group clamupdate does not exist - using root
10:19:49 : YUM: warning: user clamupdate does not exist - using root
10:19:49 : YUM: warning: group clamupdate does not exist - using root
10:19:49 : clamav-lib-0.97.8-1.fc18.x86_64 ist installiert
10:19:50 : clamav-server-0.97.8-1.fc18.x86_64 ist installiert
10:19:50 : clamav-server-systemd-0.97.8-1.fc18.noarch ist installiert
10:19:50 : RPM Scriptlet: Aufruf: groupadd [Optionen] GRUPPE
10:19:50 : YUM: Optionen:
10:19:50 : YUM:   -f, --force                   Ohne Fehler beenden, falls die Gruppe
10:19:50 : YUM:                                 bereits existiert
10:19:50 : YUM:                                 und Operation für -g abbrechen, falls die
10:19:50 : YUM:                                 GID bereits verwendet wird
10:19:50 : YUM:   -g, --gid GID                 GID für die neue Gruppe benutzen
10:19:50 : YUM:   -h, --help                    Diese Hilfe anzeigen, sonst nichts
10:19:50 : YUM:   -K, --key SCHLÜSSEL=WERT      Die Vorgabewerte in /etc/login.defs
10:19:50 : YUM:                                 überschreiben
10:19:50 : YUM:   -o, --non-unique              Erstellen einer Gruppe mit nicht
10:19:50 : YUM:                                 einmaliger (doppelter) GID erlauben
10:19:50 : YUM:   -p, --password PASSWORT       Dieses verschlüsselte PASSWORT für die
10:19:50 : YUM:                                 neue Gruppe verwenden
10:19:50 : YUM:   -r, --system                  Eine Systemgruppe erstellen
10:19:50 : YUM:   -R, --root CHROOT_VERZ        Verzeichnis für chroot
10:19:50 : YUM: useradd: Gruppe »clamscan« existiert nicht.
10:19:51 : clamav-scanner-0.97.8-1.fc18.noarch ist installiert
10:19:52 : clamav-scanner-systemd-0.97.8-1.fc18.noarch ist installiert
10:19:52 : sendmail-milter-8.14.7-1.fc18.x86_64 ist installiert
10:19:53 : RPM Scriptlet: Aufruf: groupadd [Optionen] GRUPPE
10:19:53 : YUM: Optionen:
10:19:53 : YUM:   -f, --force                   Ohne Fehler beenden, falls die Gruppe
10:19:53 : YUM:                                 bereits existiert
10:19:53 : YUM:                                 und Operation für -g abbrechen, falls die
10:19:53 : YUM:                                 GID bereits verwendet wird
10:19:53 : YUM:   -g, --gid GID                 GID für die neue Gruppe benutzen
10:19:53 : YUM:   -h, --help                    Diese Hilfe anzeigen, sonst nichts
10:19:53 : YUM:   -K, --key SCHLÜSSEL=WERT      Die Vorgabewerte in /etc/login.defs
10:19:53 : YUM:                                 überschreiben
10:19:53 : YUM:   -o, --non-unique              Erstellen einer Gruppe mit nicht
10:19:53 : YUM:                                 einmaliger (doppelter) GID erlauben
10:19:53 : YUM:   -p, --password PASSWORT       Dieses verschlüsselte PASSWORT für die
10:19:53 : YUM:                                 neue Gruppe verwenden
10:19:53 : YUM:   -r, --system                  Eine Systemgruppe erstellen
10:19:53 : YUM:   -R, --root CHROOT_VERZ        Verzeichnis für chroot
10:19:53 : YUM: useradd: Gruppe »clamilt« existiert nicht.
10:19:53 : clamav-milter-0.97.8-1.fc18.x86_64 ist installiert
10:19:53 : RPM Scriptlet: chown: ungültige Gruppe: „root:clamilt“
10:19:53 : clamav-milter-systemd-0.97.8-1.fc18.noarch ist installiert
10:19:54 : clamsmtp-1.10-10.fc18.x86_64 ist installiert
10:19:54 : clamav-update-0.97.8-1.fc18.x86_64 ist installiert
10:19:54 : RPM Scriptlet: /usr/bin/chown: ungültige Gruppe: „root:clamupdate“
10:19:55 : clamav-0.97.8-1.fc18.x86_64 ist installiert
10:19:55 : clamav-devel-0.97.8-1.fc18.x86_64 ist installiert
10:19:58 : Transaktion wurde erfolgreich ausgeführt
10:20:03 : RPM-Datenbank wird geschlossen und Yum entsperrt
10:20:03 : Yum-Backendprozess wurde beendet

Comment 40 Fedora End Of Life 2013-07-04 01:17:13 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 41 Sergio Monteiro Basto 2013-07-04 21:36:42 UTC
I think this still need review ...

Comment 42 Fedora End Of Life 2013-12-21 08:32:36 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 43 Fedora End Of Life 2014-02-05 11:53:49 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 44 Sergio Monteiro Basto 2018-01-09 00:01:44 UTC
reopen as it isn't fixed

Comment 45 Fedora End Of Life 2018-02-20 15:39:38 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 46 Stuart James 2018-07-02 09:35:10 UTC
This happens on Centos7/RHEL7 with the following packages

clamav-data-0.99.4-1.el7.noarch
clamav-lib-0.99.4-1.el7.x86_64
clamav-server-systemd-0.99.4-1.el7.noarch
clamav-scanner-systemd-0.99.4-1.el7.noarch
clamav-filesystem-0.99.4-1.el7.noarch
clamav-server-0.99.4-1.el7.x86_64
clamav-scanner-0.99.4-1.el7.noarch

The problem seems to be that tmpfiles.d uses /usr/lib/tmpfiles.d/clamd.scan.conf which is part of clamav-scanner package to set directory permission. No matter what you set as part of /etc/clamav/scan.conf matters (LocalSocket 666) because the other user can not access the socket due to the directory permissions. I did in fact add the other user to clamscan group and i can actually get into this directory (g+x permission)as the user but the application(python app) still experiences the error, only changing directory to 0711 or using setfacl resolves the issue.

Not sure why this hasn't been changed like Philip said, most of the other directories in this /var/run/ are 755 or similar allowing others to access it if they have permission on the socket. Seems like writing another systemd service to alter this directory is effectively the only *hack* that is sustainable.

Comment 47 Sergio Monteiro Basto 2018-07-12 01:08:27 UTC
OK I read this bug again 

(In reply to Philip Prindeville from comment #30)
> Created attachment 566640 [details]
> Add clamav+mimedefang integration subpackage
> 
> As comment #17 recommends.

Attachment #566640 [details]  still valid ? to include in clamav package ? 


(In reply to Philip Prindeville from comment #3)
> And let's be real here: we're talking about a trivial 1-line change:
> 
cat << EOF > $RPM_BUILD_ROOT%_sysconfdir/tmpfiles.d/clamd.scan.conf
-d %scanstatedir 0710 %scanuser %scanuser
+d %scanstatedir 0751 %scanuser %scanuser
EOF

I am considering in apply it ...   

(In reply to Philip Prindeville from comment #25)
> As a side note, the /usr/share/doc/clamav-server-0.9.73/README is wrong.
> 
> Or else the /usr/share/clamav/clamd-wrapper is.
> 
> Either the README is skipping the step where you need to create:
> 
> # echo "d /var/run/clamd.<SERVICE> 0710 <USER> clamscan" >
> /etc/tmpfiles.d/clamd.<SERVICE>.conf
> 
> but after emulating these steps by hand (or else rebooting), you still need:
> 
> # chcon -t clamd_var_run_t /var/run/clamd.<SERVICE>

OK , I will check it and about the rest, sysv and clamd-wrapper is deprecated a long time ago.

(In reply to Philip Prindeville from comment #32)
> Did you also see the change in my patch to the system .service file to
> indicate the PIDFile?

clamd@.service [1] , now don't have PrivateTmp = true , Type is not simple it is fork and ExecStart = don't have --nofork=yes . 

And in /etc/clamd.d/scan.conf the default of pidfile is disabled, so I think we don't need add PIDFile = /var/run/clamd.%i/clamd.pid 


[1]
[Unit]
Description = clamd scanner (%i) daemon
After = syslog.target nss-lookup.target network.target

[Service]
Type = forking
ExecStart = /usr/sbin/clamd -c /etc/clamd.d/%i.conf
Restart = on-failure

Comment 48 Sergio Monteiro Basto 2018-07-12 01:30:16 UTC
(In reply to Stuart James from comment #46)
> I did in fact add
> the other user to clamscan group and i can actually get into this directory
> (g+x permission)as the user but the application(python app) still
> experiences the error, only changing directory to 0711 or using setfacl
> resolves the issue.

So you suggest that dir of /var/run/clamd.scan be 750 , the be readable by user of the group ?

> Not sure why this hasn't been changed like Philip said, most of the other
> directories in this /var/run/ are 755 or similar allowing others to access
> it if they have permission on the socket. 

With permission 751 anybody may kill clamd with [1], which seems to me a good security argument 

[1] 
echo nSHUTDOWN | nc -U /run/clamd.scan/clamd.sock

Comment 49 Philip Prindeville 2018-07-12 15:05:55 UTC
(In reply to Sergio Monteiro Basto from comment #47)
> OK I read this bug again 
> 
> (In reply to Philip Prindeville from comment #30)
> > Created attachment 566640 [details]
> > Add clamav+mimedefang integration subpackage
> > 
> > As comment #17 recommends.
> 
> Attachment #566640 [details]  still valid ? to include in clamav package ? 

No idea.  After 6 years I've lost the thread.

> (In reply to Philip Prindeville from comment #3)
> > And let's be real here: we're talking about a trivial 1-line change:
> > 
> cat << EOF > $RPM_BUILD_ROOT%_sysconfdir/tmpfiles.d/clamd.scan.conf
> -d %scanstatedir 0710 %scanuser %scanuser
> +d %scanstatedir 0751 %scanuser %scanuser
> EOF
> 
> I am considering in apply it ...

Great.  I'm not sure what works any more and I don't have time to debug it all over again.

Maybe Sergio has more insight at this point.

Comment 50 Sergio Monteiro Basto 2018-07-12 15:18:06 UTC
(In reply to Philip Prindeville from comment #49)
> (In reply to Sergio Monteiro Basto from comment #47)
> > OK I read this bug again 
> > 
> > (In reply to Philip Prindeville from comment #30)

> No idea.  After 6 years I've lost the thread.

Attachment #566640 [details] is about server-systemd-mimedefang still interesting in mimedefang sub-package ?  


> > (In reply to Philip Prindeville from comment #3)
> > > And let's be real here: we're talking about a trivial 1-line change:
> > > 
> > cat << EOF > $RPM_BUILD_ROOT%_sysconfdir/tmpfiles.d/clamd.scan.conf
> > -d %scanstatedir 0710 %scanuser %scanuser
> > +d %scanstatedir 0751 %scanuser %scanuser
> > EOF
> > 
> > I am considering in apply it ...
> 
> Great.  I'm not sure what works any more and I don't have time to debug it
> all over again.
> 
> Maybe Sergio has more insight at this point.

Maybe I will ask upstream (permissions of socket vs permissions of directory ). 
After thinking doesn't seemed to me wise modify this permissions .

The point here is all the rest is fixed, just left these 3 details (these 2 more one line in documentation).

Thanks.

Comment 51 Sergio Monteiro Basto 2018-07-18 01:11:09 UTC
*** Bug 1284253 has been marked as a duplicate of this bug. ***

Comment 52 Fedora Update System 2018-07-29 07:56:16 UTC
clamav-0.100.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-331381dee5

Comment 53 Fedora Update System 2018-07-29 07:57:29 UTC
clamav-0.100.1-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8b6214e6ae

Comment 54 Fedora Update System 2018-07-29 07:58:26 UTC
clamav-0.100.1-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ecad18a061

Comment 55 Fedora Update System 2018-07-29 23:51:13 UTC
clamav-0.100.1-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-8b6214e6ae

Comment 56 Fedora Update System 2018-07-29 23:59:28 UTC
clamav-0.100.1-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ecad18a061

Comment 57 Fedora Update System 2018-07-30 01:26:53 UTC
clamav-0.100.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-331381dee5

Comment 58 Fedora Update System 2018-07-31 03:34:53 UTC
clamav-0.100.1-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-61b6e4545f

Comment 59 Fedora Update System 2018-07-31 03:35:39 UTC
clamav-0.100.1-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c1c78a6e35

Comment 60 Fedora Update System 2018-07-31 15:25:20 UTC
clamav-0.100.1-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c1c78a6e35

Comment 61 Fedora Update System 2018-07-31 18:33:25 UTC
clamav-0.100.1-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-61b6e4545f

Comment 62 Fedora Update System 2018-08-07 01:16:02 UTC
clamav-0.100.1-4.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 63 Fedora Update System 2018-08-22 10:43:09 UTC
clamav-0.100.1-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 64 Fedora Update System 2018-09-18 07:22:31 UTC
clamav-0.100.1-3.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.

Comment 65 Woti 2019-04-13 21:13:08 UTC
Problem still persistent in Fedora 29.

Comment 66 Sergio Monteiro Basto 2019-04-13 22:31:11 UTC
(In reply to Woti from comment #65)
> Problem still persistent in Fedora 29.

ll  /var/run/clamd.scan/ -d
drwx--x--- 2 clamscan virusgroup 40 abr  8 21:36 /var/run/clamd.scan/

is correct, what is your problem ?

Comment 67 Woti 2019-04-14 15:51:44 UTC
It's wrong. Permissions should be 755 not 710. As it is descripet her https://bugzilla.redhat.com/show_bug.cgi?id=1284253.
We get a lot of permission errors in Nextcloud if we want to use clamav as descripet her: https://docs.nextcloud.com/server/15/admin_manual/configuration_server/antivirus_configuration.html

Changing manually from 710 to 755 is working. I'm running Fedora 29 Server-Edition with Nextcloud and ClamAv installed. If I do need to restart the server once in a while, every time I have to change the permissions to get ClamAV working properly.

Comment 68 Sergio Monteiro Basto 2019-04-15 11:17:33 UTC
Thanks for the report .

Changing from 710 to 755 is a big security hole , as describe in these reports . 

I think you need add the user that needs to access to clamav socket to virusgroup and you will have permissions of the group .

If I have time I will check nextcloud running with clamav .

Feel free to reply .


Thanks.

Comment 69 Woti 2019-04-16 09:53:29 UTC
I did some testing. I added the user "apache" to the group "virusgroup" and the following error messages disappeared:

[files_antivirus] Fatal: OCA\Files_Antivirus\BackgroundJob\BackgroundScanner::run, exception: Cannot connect to "/var/run/clamd.scan/clamd.sock": Permission denied (code 13)

{"reqId":"h9b0q8yuvhYLncMjvdtQ","level":4,"time":"2019-04-16T10:45:44+02:00","remoteAddr":"","user":"--","app":"files_antivirus","method":"","url":"--","message":"OCA\\Files_Antivirus\\BackgroundJob\\BackgroundScanner::run, exception: Cannot connect to \"/var/run/clamd.scan/clamd.sock\": Permission denied (code 13)","userAgent":"--","version":"15.0.7.0","id":"5cb5970ae7f69"}

[PHP] Error: stream_socket_client(): unable to connect to unix:///var/run/clamd.scan/clamd.sock (Permission denied) at /var/www/html/nextcloud/apps/files_antivirus/lib/Scanner/External.php#41

{"reqId":"h9b0q8yuvhYLncMjvdtQ","level":3,"time":"2019-04-16T10:45:44+02:00","remoteAddr":"","user":"--","app":"PHP","method":"","url":"--","message":"stream_socket_client(): unable to connect to unix:///var/run/clamd.scan/clamd.sock (Permission denied) at /var/www/html/nextcloud/apps/files_antivirus/lib/Scanner/External.php#41","userAgent":"--","version":"15.0.7.0","id":"5cb5970ae7f8d"}

It looks like it works. I'll will do some more testing just to be sure and give you a reply.

Comment 70 Stuart James 2019-04-16 10:00:27 UTC
I dont think that alone makes it a security issue the socket still needs permission right? For example


in scan.conf
```
LocalSocketMode 660
```

If you run that as regular user after giving /var/run/clamd.scan necessary O+X it won't do anything as you still dont have access to socket itself unless you choose to enable it

```
echo nSHUTDOWN | nc -U /var/run/clamd.scan/clamd.sock
```

Only if you set the LocalSocketMode to 666 then sure it will but that is choice of user to do that like any other setting on the server (such as setenforce 0)

The problem is that the Localsocketmode is useless for Other as access to directory is not allowed by some other configuration that is really not doing anything but preventing O+X. Pretty much all other directories in /run are 755 so not really sure why this one needs not to be.

If a user decides to turn off Selinux or to allow Other access to socket then it should be possible, it assumes you are running this on some sorta shared multi-user environment which is probably not the case.

As per my above problem i have user in another primary group running an Python application, adding that user to clamscan group did not fix the problem, maybe if it was added to clamscan group as primary group it would work but that is not an option. 

In the end we moved the socket to a location we can control the access of the director without hacking a SystemD config as per the above comments. ideally the localsockemode is what defines if an Other user has access not the temporary directory where socket is created.

Comment 71 Sergio Monteiro Basto 2019-04-16 13:12:38 UTC
TLDR 

have file permissions with 755 and socket wiht 660 is the same 750 with socket 666 .

Comment 72 Stuart James 2019-04-16 13:25:59 UTC
The directory is wrong permission when created, the localsocketmode should control who should be able to access the socket.

This was in comment 9 in 2012 by Phil and still remains the same.

The default should be 660 on the socket (as it is) but a user should be able to modify it and not have to worry about some useless directory permission that is only interfering with the configuration of the actual application.

Comment 73 Sergio Monteiro Basto 2019-04-16 18:48:54 UTC
cat /usr/lib/tmpfiles.d/clamd.scan.conf
d /run/clamd.scan 0710 clamscan virusgroup

is the correct, I already argued many times, epel 7 is now with this configuration and everyone is happy . 

what we may do is update nextcloud documentation [1] 
yum/dnf install clamav-update clamav
add user apache to virusgroup  etc etc 

[1]
https://github.com/nextcloud/documentation/edit/master/admin_manual/configuration_server/antivirus_configuration.rst

Comment 74 Woti 2019-04-16 19:47:39 UTC
I can confirm that it is working with Apache, if added to the group "virusgroup". No need to change the folder permission of /var/run/clamd.scan/ from 710 to 755.
There are no more error messages apearing in the Nextcloud log file. 

This should have been updated in the Nextcloud documentation long ago.

id apache
uid=48(apache) gid=48(apache) Gruppen=48(apache),976(virusgroup)

cat /usr/lib/tmpfiles.d/clamd.scan.conf
d /run/clamd.scan 0710 clamscan virusgroup


Note You need to log in before you can comment on or make changes to this bug.