Bug 2777

Summary:	msec reports group writable on /var/cache/davfs2
Product:	Mageia	Reporter:	Neil Darlow <neil>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	Normal	CC:	marja11, neil
Version:	1	Keywords:	UPSTREAM
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	davfs2 msec	CVE:
Status comment:

Description Neil Darlow 2011-09-19 10:38:32 CEST

The daily output from msec reports that /var/cache/davfs2 is group writable.

Sure enough it is owner:group root:davfs2 and mode 01775. To quiet msec would it be better for the directory permissions to be?

owner:group davfs2:davfs2 and mode 01755

Regards,
Neil Darlow

Neil Darlow 2011-09-19 10:39:21 CEST

CC: (none) => neil

Comment 1 Neil Darlow 2011-09-20 11:50:24 CEST

I believe the same is needed for /var/run/mount.davfs2 directory also.

Manuel Hiebel 2011-09-20 14:12:49 CEST

Source RPM: (none) => davfs2

Comment 2 Marja Van Waes 2011-11-30 22:32:02 CET

Hi Neil,

Sorry for replying so late, we are very short on triagers.

I read something here: https://bugzilla.redhat.com/show_bug.cgi?id=488858
"Note to reviewer: The following non-standard file permissions are all expected:
/usr/sbin/mount.davfs: suid root
/etc/davfs2/certs/private, /etc/davfs2/secrets: only readable by root
/var/cache/davfs2, /var/run/mount.davfs: writeable by 'davfs2' group
/var/run/mount.davfs: sticky bit set (mode 01xxx)"

The manpages confirm that (at least in my none-developer's eyes)

So if IIUC, there is nothing wrong, except that msec works a bit too good and that that irritates.

cc'ing the maintainer of msec and someone who committed davfs2 for Mdv last year.

@ Funda
@ DMorgan

Is it true that nothing is wrong except msec giving a false alarm?
(If so, what is the proper way to stop msec from doing that?)

CC: (none) => marja11
Source RPM: davfs2 => davfs2 msec

Comment 3 Marja Van Waes 2012-01-25 13:53:11 CET

@ Neil

Whatever way it is, whether davfs2 or msec or both should behave differently, in both cases it is an upstream issue.

davfs upstream is here
http://savannah.nongnu.org/projects/davfs2

msec upstream is Mandriva 
http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/msec/

In fact, this was already reported (with other issues) in the Mandriva forum:
http://forum.mandriva.com/en/viewtopic.php?t=131055 

And answered by
> Ahmad Samir Â» August 19th, 2010, 11:32 pm
> You don't need to worry about davfs home:

> Code: Select all
    # ls -ld /var/run/mount.davfs2
    drwxrwxr-t 2 root davfs2 4096 2010-08-09 15:44 /var/run/mount.davfs2/

> this is done on purpose, and I think the davfs won't work otherwise, not that > the dir is owned by root and the group is davfs2. You can safely ignore the
> msec warning about this (msec is being too ideal here). 

Neil, do you agree on closing this bug, or do you choose to report upstream? If you prefer to report upstream, can you please give the link to your upstream report? Thanks

Keywords: (none) => UPSTREAM

Comment 4 Neil Darlow 2012-01-25 14:17:20 CET

I guess we can close it.

As msec, and chkrootkit, report numerous violations and the general advice is that these things are ok and can be ignored.

My general feeling is to not install chkrootkit and just delete the msec mailings.

Comment 5 Marja Van Waes 2012-01-25 14:40:43 CET

Thanks, Neil :)

Closing

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX