On 2/9/2010 9:13 PM, Ola Lundqvist wrote: >> When setting the correct permissions (u=rx,g=rxs,o= with ownership >> ntop:ntop) on the directory, the permissions will always be ok: >> - the directory will not be accessible by anyone else than ntop, >> - the contained files will have appropriate rights to be read/written by >> ntop. (I dislike the fact that they still are o=rw, but that doesn't >> matter in that case) > > I thought the complaint in the first place was that it was o=rw?
Yes, I looked for a solution that would make - the files not accessible to everyone - still readable/writeable to ntop We may of course give a correct umask to ntop, but if files are owned by root and have no permission for "other", they will not be writeable by user ntop, no matter what the umask. Let's take the example of the /var/log/clamav, which would be an example for correct permissions: drwxr-xr-x 2 clamav clamav 4096 Feb 7 21:44 . drwxr-xr-x 34 root root 57344 Feb 9 00:04 .. -rw-r----- 1 clamav adm 4483 Feb 9 21:19 clamav.log "-rw-r-----" is probably achieved by setting a correct umask, and "clamav adm" is achieved by either - telling the daemon how to correctly create those files (which ntop seems not to be able to), or - make them automatically belong to the right user by using setgid on the directory (since ntop seems not to be able to do so itself) >> If you remove the directory altogether, ntop will no longer start: >> "Starting network top daemon: ERR: logging directory /var/log/ntop does >> not exist will not start network top daemon!" > > What I ment was to remove the files, only. Not the dir. They will again be created "rw-rw-rw root:root" when ntop is next run. >> I'm not sure what happens on an upgrade. Is postinst run on upgrade? If >> it is, then permissions would be correct afterwards. > > Postinst is run on upgrade, yes. > > My issue is if someone do not upgrade. :-) The "fresh install" case was the case that I was talking about all along. And if postinst is run on upgrade then the upgrade case will not be an issue. JM -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
