Hi On Tue, Feb 09, 2010 at 09:25:44PM +0100, J.M.Roth wrote: > 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
Makes perfect sense. > 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. Agree. > 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) Yes. > >> 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. Yes. > >> 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. The only problem I see with the postinst solution is that it is run on install or upgrade only. But it is a way to solve the group permissions. I agree with that. So now I only need to find a way to set the umask, as you have solved the directory permission problem. Best regards, // Ola > JM > > > -- --------------------- Ola Lundqvist --------------------------- / o...@debian.org Annebergsslingan 37 \ | o...@inguza.com 654 65 KARLSTAD | | http://inguza.com/ +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
