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
CC: (none) => neil
I believe the same is needed for /var/run/mount.davfs2 directory also.
Source RPM: (none) => davfs2
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) => marja11Source RPM: davfs2 => davfs2 msec
@ 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
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.
Thanks, Neil :) Closing
Status: NEW => RESOLVEDResolution: (none) => WONTFIX