Hi Stephane, 

thanks for your investigation on this issue, my comments below.

On Wed, Oct 12, 2011 at 08:17:53PM +0100, Stephane Chazelas wrote:
> Package: c-icap
> Version: 1:0.1.6-1
> Severity: normal
> 
> Hiya,
> 
> The named pipe used to send control requests to the c-icap
> server has incorrect permissions. That could even be considered
> as a security issue as any user on the system can cause some of
> the requests to c-icap to not be delivered to it or be
> misinterpreted (by reading that file).
> 
> $ ll /var/run/c-icap/c-icap.ctl
> prwxr--r-- 1 c-icap nogroup 0 Oct 12 19:20 /var/run/c-icap/c-icap.ctl|
> 
> Anybody can read from that fifo. Also, the gid is "nogroup".
> That group shouldn't have any right. See the execution bit for
> the user which doesn't make sense here either.

Your right, the permission isn't optimal. The GID ist choosen from the config
file and therefore can be changed. I will update the package soon to 0.1.7 and
will implement an c-icap group and switch default config to use this group.
 
> Also,  /usr/share/doc/libc-icap-mod-clamav/README.Debian
> instructs how to configure freshclam so that c-icap reloads the
> virus db when it gets updated, but because freshclam is running
> as "clamav", those instructions don't work because clamav
> doesn't have right access to that named pipe.
> 
> IMO, the permissions should be:
> 
> prw--w---- c-icap c-icap
> 
> The c-icap group should be added and c-icap should run as
> c-icap:c-icap, the clamav user shoud be made member of that group.

Will look into this, if we do it via install scripts or just inform user about
the steps. Maybe someone don't want this integration or maybe someone runs
clamav on some other userid.

> As it happens, the permissions of the named pipe are hardcoded
> in the the c-icap source code. It would be nice to have a
> configuration parameter to specify that mode, or be able to use
> umask to set it.

You can use umask to change the permissions, as the source code uses
mkfifo which can be tweak by umask settings within the init script (umask
option for start-stop-daemon). Problem i think is that you can not set the
initial mode for the file, so umask fiddling is just hard.
 
> Also, it seems c-icap puts itself in background *before*
> creating that pipe, which makes it difficult to fix the
> permissions reliably in c-icap init.d startup script.

Yes, but if we use proper named pipe creation within the Package installation
scripts, we can create the named pipe, the daemon will not mess with the named
pipe if it already exists.

But will look for an patch for hardcoded mode settings and discuss this with
upstream.

cheers, 
tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8

Attachment: signature.asc
Description: Digital signature

Reply via email to