Bug#568641: ntop: access.log is writeable by everyone
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
Bug#568641: ntop: access.log is writeable by everyone
On 2/9/2010 8:45 AM, Ola Lundqvist wrote: On Mon, Feb 08, 2010 at 11:24:52PM +0100, J.M.Roth wrote: On 2/8/2010 11:13 PM, Ola Lundqvist wrote: drwxr-xr-x 2 ntop root 4096 2010-01-27 11:18 . drwxr-xr-x 12 root root 4096 2010-01-27 11:17 .. -rw-rw-rw- 1 root root0 2010-01-27 11:18 access.log Not good. However I do not think postinst is good enough. We must change the umask instead so that it is created correctly. But umask would just change permissions like chmod. Even when others could no longer read/write to the file due to changes to the umask, the ntop user also wouldn't be able to anymore. More can't be accomplished by playing with the umask. Yes, but what happens in the following case: 1) Someone install the package 2) Run ntop (log created) 3) Clean log files 4) Run ntop again (with -A) Now logfiles are there still with writeable access log. Your solution only works on upgrade (or did I completely misunderstood you?) 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) 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! I'm not sure what happens on an upgrade. Is postinst run on upgrade? If it is, then permissions would be correct afterwards. JM -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568641: ntop: access.log is writeable by everyone
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
Bug#568641: ntop: access.log is writeable by everyone
Hi On Tue, Feb 09, 2010 at 10:52:51AM +0100, J.M.Roth wrote: On 2/9/2010 8:45 AM, Ola Lundqvist wrote: On Mon, Feb 08, 2010 at 11:24:52PM +0100, J.M.Roth wrote: On 2/8/2010 11:13 PM, Ola Lundqvist wrote: drwxr-xr-x 2 ntop root 4096 2010-01-27 11:18 . drwxr-xr-x 12 root root 4096 2010-01-27 11:17 .. -rw-rw-rw- 1 root root0 2010-01-27 11:18 access.log Not good. However I do not think postinst is good enough. We must change the umask instead so that it is created correctly. But umask would just change permissions like chmod. Even when others could no longer read/write to the file due to changes to the umask, the ntop user also wouldn't be able to anymore. More can't be accomplished by playing with the umask. Yes, but what happens in the following case: 1) Someone install the package 2) Run ntop (log created) 3) Clean log files 4) Run ntop again (with -A) Now logfiles are there still with writeable access log. Your solution only works on upgrade (or did I completely misunderstood you?) 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? 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. 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. :-) 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
Bug#568641: ntop: access.log is writeable by everyone
On 2/8/2010 7:54 AM, Ola Lundqvist wrote: /var/log/access.log is writeable by everyone. The following would fix that: The file or the directory? My file has the following permission: drwxr-xr-x 2 ntop root 89 May 10 2009 . drwxr-xr-x 15 root root4096 Feb 8 01:21 .. -rw--- 1 ntop ntop 0 May 10 2009 access.log -rw--- 1 ntop ntop 1495082 May 8 2009 access.log.1.gz -rw--- 1 ntop ntop 263209 May 6 2009 access.log.2.gz -rw--- 1 ntop ntop 50469 Nov 12 2006 access.log.3.gz Maybe you did that yourself sometime in the past? After installation (not upgrade) on two independent Lenny systems: - aptitude install ntop - ntop -A - /etc/init.d/ntop start my log directory looks like this: drwxr-xr-x 2 ntop root 4096 2010-01-27 11:18 . drwxr-xr-x 12 root root 4096 2010-01-27 11:17 .. -rw-rw-rw- 1 root root0 2010-01-27 11:18 access.log + chown -Rf $USER: /var/log/ntop Why changing this? Why the ':' character? To make the group of the directory the primary group of the user (i.e. ntop) we just chowned to. +# content of log dir inherits group permission +chmod g+s,o= /var/log/ntop Why do you want to inherit the root group permissions? Because the files need to be writeable to ntop. After the above, files will belong to group ntop (like the directory). So ntop will be able to access (read/write) them. JM -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568641: ntop: access.log is writeable by everyone
Hi On Mon, Feb 08, 2010 at 11:02:49AM +0100, J.M.Roth wrote: On 2/8/2010 7:54 AM, Ola Lundqvist wrote: /var/log/access.log is writeable by everyone. The following would fix that: The file or the directory? My file has the following permission: drwxr-xr-x 2 ntop root 89 May 10 2009 . drwxr-xr-x 15 root root4096 Feb 8 01:21 .. -rw--- 1 ntop ntop 0 May 10 2009 access.log -rw--- 1 ntop ntop 1495082 May 8 2009 access.log.1.gz -rw--- 1 ntop ntop 263209 May 6 2009 access.log.2.gz -rw--- 1 ntop ntop 50469 Nov 12 2006 access.log.3.gz Maybe you did that yourself sometime in the past? No I do not think so, but it was not a fresh install. After installation (not upgrade) on two independent Lenny systems: - aptitude install ntop - ntop -A - /etc/init.d/ntop start my log directory looks like this: drwxr-xr-x 2 ntop root 4096 2010-01-27 11:18 . drwxr-xr-x 12 root root 4096 2010-01-27 11:17 .. -rw-rw-rw- 1 root root0 2010-01-27 11:18 access.log Not good. However I do not think postinst is good enough. We must change the umask instead so that it is created correctly. + chown -Rf $USER: /var/log/ntop Why changing this? Why the ':' character? To make the group of the directory the primary group of the user (i.e. ntop) we just chowned to. Ok, thanks. Did not know about that syntax. +# content of log dir inherits group permission +chmod g+s,o= /var/log/ntop Why do you want to inherit the root group permissions? Because the files need to be writeable to ntop. After the above, files will belong to group ntop (like the directory). So ntop will be able to access (read/write) them. Ok. I see. I'll see if I can find the place where the file is created so we can have proper permissions at that time. 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
Bug#568641: ntop: access.log is writeable by everyone
On 2/8/2010 11:13 PM, Ola Lundqvist wrote: drwxr-xr-x 2 ntop root 4096 2010-01-27 11:18 . drwxr-xr-x 12 root root 4096 2010-01-27 11:17 .. -rw-rw-rw- 1 root root0 2010-01-27 11:18 access.log Not good. However I do not think postinst is good enough. We must change the umask instead so that it is created correctly. But umask would just change permissions like chmod. Even when others could no longer read/write to the file due to changes to the umask, the ntop user also wouldn't be able to anymore. More can't be accomplished by playing with the umask. I'll see if I can find the place where the file is created so we can have proper permissions at that time. AFAICS the file is created by ntop at runtime if it is not there before. It is thus given the permissions by the operating system. Therefore I had tuned the directory permissions. JM PS. Maybe it works fine at a second glance because logrotate correctly uses create 640 ntop adm, however the initial install is not fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568641: ntop: access.log is writeable by everyone
Hi On Mon, Feb 08, 2010 at 11:24:52PM +0100, J.M.Roth wrote: On 2/8/2010 11:13 PM, Ola Lundqvist wrote: drwxr-xr-x 2 ntop root 4096 2010-01-27 11:18 . drwxr-xr-x 12 root root 4096 2010-01-27 11:17 .. -rw-rw-rw- 1 root root0 2010-01-27 11:18 access.log Not good. However I do not think postinst is good enough. We must change the umask instead so that it is created correctly. But umask would just change permissions like chmod. Even when others could no longer read/write to the file due to changes to the umask, the ntop user also wouldn't be able to anymore. More can't be accomplished by playing with the umask. Yes, but what happens in the following case: 1) Someone install the package 2) Run ntop (log created) 3) Clean log files 4) Run ntop again (with -A) Now logfiles are there still with writeable access log. Your solution only works on upgrade (or did I completely misunderstood you?) I'll see if I can find the place where the file is created so we can have proper permissions at that time. AFAICS the file is created by ntop at runtime if it is not there before. It is thus given the permissions by the operating system. Therefore I had tuned the directory permissions. Yes, but the permissions is given by the operating system based on the umask of the running program. That is why the usmask must be changed as well. JM PS. Maybe it works fine at a second glance because logrotate correctly uses create 640 ntop adm, however the initial install is not fine. Ok. That was good to know. But initial is not good just as you points out. Best regards, // Ola -- - 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
Bug#568641: ntop: access.log is writeable by everyone
Hi On Sat, Feb 06, 2010 at 02:11:25PM +0100, J.M.Roth wrote: Package: ntop Version: 3:3.3-11+b2 Severity: normal Tags: patch, security /var/log/access.log is writeable by everyone. The following would fix that: The file or the directory? My file has the following permission: drwxr-xr-x 2 ntop root 89 May 10 2009 . drwxr-xr-x 15 root root4096 Feb 8 01:21 .. -rw--- 1 ntop ntop 0 May 10 2009 access.log -rw--- 1 ntop ntop 1495082 May 8 2009 access.log.1.gz -rw--- 1 ntop ntop 263209 May 6 2009 access.log.2.gz -rw--- 1 ntop ntop 50469 Nov 12 2006 access.log.3.gz --- postinst2008-08-06 17:55:17.0 +0200 +++ postinst.new2010-02-06 14:07:59.0 +0100 @@ -35,14 +35,17 @@ adduser --system --group --home /var/lib/ntop $USER fi -# make status dir owned by user if grep -q ^$USER: /etc/passwd; then +# make status dir owned by user chown -Rf $USER /var/lib/ntop - chown -Rf $USER /var/log/ntop +# make log dir owned by user and group + chown -Rf $USER: /var/log/ntop Why changing this? Why the ':' character? fi fi -chmod o-rx /var/lib/ntop +chmod o= /var/lib/ntop +# content of log dir inherits group permission +chmod g+s,o= /var/log/ntop Why do you want to inherit the root group permissions? Best regards, // Ola echo USER=\$USER\ $INITCFG echo INTERFACES=\$INTERFACES\ $INITCFG -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages ntop depends on: ii adduser 3.110add and remove users and groups ii debconf [debconf-2. 1.5.24 Debian configuration management sy ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libcairo2 1.6.4-7 The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype62.3.7-2+lenny1 FreeType 2 font engine, shared lib ii libgdbm31.8.3-3 GNU dbm database routines (runtime ii libglib2.0-02.16.6-3 The GLib library of C routines ii libpango1.0-0 1.20.5-5 Layout and rendering of internatio ii libpcap0.8 0.9.8-5 system interface for user-level pa ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a ii libpng12-0 1.2.27-2+lenny2 PNG library - runtime ii librrd4 1.3.1-4 Time-series data storage and displ ii libssl0.9.8 0.9.8g-15+lenny6 SSL shared libraries ii libx11-62:1.1.5-2X11 client-side library ii libxcb-render-util0 0.2.1+git1-1 utility libraries for X C Binding ii libxcb-render0 1.1-1.2 X C Binding, render extension ii libxcb1 1.1-1.2 X C Binding ii libxml2 2.6.32.dfsg-5+lenny1 GNOME XML library ii libxrender1 1:0.9.4-2X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime ntop recommends no packages. Versions of packages ntop suggests: ii graphviz 2.20.2-3 rich set of graph drawing tools ii gsfonts 1:8.11+urwcyr1.0.7~pre44-3 Fonts for the Ghostscript interpre -- debconf information: * ntop/interfaces: eth0 * ntop/user: ntop -- - 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
Bug#568641: ntop: access.log is writeable by everyone
Package: ntop Version: 3:3.3-11+b2 Severity: normal Tags: patch, security /var/log/access.log is writeable by everyone. The following would fix that: --- postinst2008-08-06 17:55:17.0 +0200 +++ postinst.new2010-02-06 14:07:59.0 +0100 @@ -35,14 +35,17 @@ adduser --system --group --home /var/lib/ntop $USER fi -# make status dir owned by user if grep -q ^$USER: /etc/passwd; then +# make status dir owned by user chown -Rf $USER /var/lib/ntop - chown -Rf $USER /var/log/ntop +# make log dir owned by user and group + chown -Rf $USER: /var/log/ntop fi fi -chmod o-rx /var/lib/ntop +chmod o= /var/lib/ntop +# content of log dir inherits group permission +chmod g+s,o= /var/log/ntop echo USER=\$USER\ $INITCFG echo INTERFACES=\$INTERFACES\ $INITCFG -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages ntop depends on: ii adduser 3.110add and remove users and groups ii debconf [debconf-2. 1.5.24 Debian configuration management sy ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libcairo2 1.6.4-7 The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype62.3.7-2+lenny1 FreeType 2 font engine, shared lib ii libgdbm31.8.3-3 GNU dbm database routines (runtime ii libglib2.0-02.16.6-3 The GLib library of C routines ii libpango1.0-0 1.20.5-5 Layout and rendering of internatio ii libpcap0.8 0.9.8-5 system interface for user-level pa ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a ii libpng12-0 1.2.27-2+lenny2 PNG library - runtime ii librrd4 1.3.1-4 Time-series data storage and displ ii libssl0.9.8 0.9.8g-15+lenny6 SSL shared libraries ii libx11-62:1.1.5-2X11 client-side library ii libxcb-render-util0 0.2.1+git1-1 utility libraries for X C Binding ii libxcb-render0 1.1-1.2 X C Binding, render extension ii libxcb1 1.1-1.2 X C Binding ii libxml2 2.6.32.dfsg-5+lenny1 GNOME XML library ii libxrender1 1:0.9.4-2X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime ntop recommends no packages. Versions of packages ntop suggests: ii graphviz 2.20.2-3 rich set of graph drawing tools ii gsfonts 1:8.11+urwcyr1.0.7~pre44-3 Fonts for the Ghostscript interpre -- debconf information: * ntop/interfaces: eth0 * ntop/user: ntop -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
