messed up permissions on /dev/null destination on solaris
When using /dev/null as a destination on Solaris 8 (sparc) with syslog-ng 1.6.7 the perms of /dev/null get messed up: $ ls -l /dev/null lrwxrwxrwx 1 root other 27 Apr 19 2003 /dev/null -> ../devices/pseudo/mm@0:null $ ls -l /devices/pseudo/mm@0:null crw-r--r-- 1 root root 13, 2 Oct 16 18:27 /devices/pseudo/mm@0:null I thought this was addressed at some point, was that only on Linux perhaps? Thanks, -- Nate "Hardware : The parts of a computer system that can be kicked." - Pesis, Jeff
On Sun, Oct 16, 2005 at 11:39:21AM -0700, Nate Campi wrote:
When using /dev/null as a destination on Solaris 8 (sparc) with syslog-ng 1.6.7 the perms of /dev/null get messed up:
$ ls -l /dev/null lrwxrwxrwx 1 root other 27 Apr 19 2003 /dev/null -> ../devices/pseudo/mm@0:null $ ls -l /devices/pseudo/mm@0:null crw-r--r-- 1 root root 13, 2 Oct 16 18:27 /devices/pseudo/mm@0:null
I thought this was addressed at some point, was that only on Linux perhaps?
Oh, of course I'm going to manually set the correct perms with perm() in the file destination clause, but I thought we made this automatic is my point. -- Nate "Confucius say: He who play in root, eventually kill tree."
On Sun, 2005-10-16 at 11:52 -0700, Nate Campi wrote:
On Sun, Oct 16, 2005 at 11:39:21AM -0700, Nate Campi wrote:
When using /dev/null as a destination on Solaris 8 (sparc) with syslog-ng 1.6.7 the perms of /dev/null get messed up:
$ ls -l /dev/null lrwxrwxrwx 1 root other 27 Apr 19 2003 /dev/null -> ../devices/pseudo/mm@0:null $ ls -l /devices/pseudo/mm@0:null crw-r--r-- 1 root root 13, 2 Oct 16 18:27 /devices/pseudo/mm@0:null
I thought this was addressed at some point, was that only on Linux perhaps?
Oh, of course I'm going to manually set the correct perms with perm() in the file destination clause, but I thought we made this automatic is my point.
I can't remember doing so, syslog-ng 1.6 issues a warning in this case, but nothing else. I'm wondering what the best solution would be. My idea is to completely refuse changing permissions if the filename begins with /dev (and don't issue a log message), is that reasonable? -- Bazsi
--On Monday, October 17, 2005 01:06:34 PM +0200 Balazs Scheidler <bazsi@balabit.hu> wrote:
I'm wondering what the best solution would be. My idea is to completely refuse changing permissions if the filename begins with /dev (and don't issue a log message), is that reasonable?
Personally, I lean toward "You told me to do something stupid, and I'm doing it" (i.e. set the permissions as asked). If you are going to hack around operator error, please don't check the pathname. Check if the file is a device special file (you may want to include FIFOs). -- Carson
On Mon, Oct 17, 2005 at 11:19:58AM -0400, Carson Gaspar wrote:
--On Monday, October 17, 2005 01:06:34 PM +0200 Balazs Scheidler <bazsi@balabit.hu> wrote:
I'm wondering what the best solution would be. My idea is to completely refuse changing permissions if the filename begins with /dev (and don't issue a log message), is that reasonable?
Personally, I lean toward "You told me to do something stupid, and I'm doing it" (i.e. set the permissions as asked).
That makes sense in most cases, but this seems a little different. I think that the vast majority of the people sending logs to /dev/null don't want its permissions changed, so maybe we should make that the default. It's certainly not the normal UNIX philosophy, but it seems like a nice way to take care of what's almost certainly a mistake. Sure, you could also just let them shoot themselves in the foot - the normal UNIX way. Whatever Bazsi wants I suppose. It's not even that I really care if it's implemented in the future, but for some reason I thought it had been in the past. -- Nate "Plonk /excl./: The sound a newbie makes as he falls to the bottom of a kill file." - From the Jargon File.
On Mon, Oct 17, 2005 at 11:19:58AM -0400, Carson Gaspar wrote:
--On Monday, October 17, 2005 01:06:34 PM +0200 Balazs Scheidler <bazsi@balabit.hu> wrote:
I'm wondering what the best solution would be. My idea is to completely refuse changing permissions if the filename begins with /dev (and don't issue a log message), is that reasonable?
Personally, I lean toward "You told me to do something stupid, and I'm doing it" (i.e. set the permissions as asked).
If you are going to hack around operator error, please don't check the pathname. Check if the file is a device special file (you may want to include FIFOs).
Checking for the type of device is a good idea, permissions on devices are usually set at installation time or otherwise by the admin, and it is a big surprise when they get changed. But let's go one level deeper - why are the "operators" configuring syslog-ng.conf to write to /dev/null in the first place and thus making this error? It's because the sysadmins want to discard certain log entries. Why not facilitate that by making a special "discard" destination? Surely that has to more efficient than opening up /dev/null, possibly changing its permissions, and then writing data to it on a regular basis just to get thrown away. -- Ed
On Mon, Oct 17, 2005 at 11:57:37AM -0400, Ed Ravin wrote:
But let's go one level deeper - why are the "operators" configuring syslog-ng.conf to write to /dev/null in the first place and thus making this error? It's because the sysadmins want to discard certain log entries. Why not facilitate that by making a special "discard" destination? Surely that has to more efficient than opening up /dev/null, possibly changing its permissions, and then writing data to it on a regular basis just to get thrown away.
When I permanently plan to ignore certain messages, I just don't log them: filter f_not_pix { not match("%PIX"); }; log { source(local); filter(f_not_pix); destination(d_loghost_tcp); }; My "f_not_pix" just internally discards it. Your idea of using a special "discard" destination would help make syslog-ng config files more self-explanatory though, which IMO is a fantastic thing. Reading my configs I would have to use a final flag to show that the message isn't logged again, and missing that the reader would have to inspect the rest of the file to understand if anything else would be done with a particular event. I normally only use /dev/null temporarily, when a firewall blocks a destination and I don't just want to leave syslog-ng trying to connect and overflowing the destination buffer for no reason. I modify the destination clause to use /dev/null for a bit. -- Nate "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." - Lamport, Leslie as quoted in CACM, June 1992
On Mon, 2005-10-17 at 09:18 -0700, Nate Campi wrote:
On Mon, Oct 17, 2005 at 11:57:37AM -0400, Ed Ravin wrote:
But let's go one level deeper - why are the "operators" configuring syslog-ng.conf to write to /dev/null in the first place and thus making this error? It's because the sysadmins want to discard certain log entries. Why not facilitate that by making a special "discard" destination? Surely that has to more efficient than opening up /dev/null, possibly changing its permissions, and then writing data to it on a regular basis just to get thrown away.
When I permanently plan to ignore certain messages, I just don't log them:
filter f_not_pix { not match("%PIX"); };
log { source(local); filter(f_not_pix); destination(d_loghost_tcp); };
My "f_not_pix" just internally discards it. Your idea of using a special "discard" destination would help make syslog-ng config files more self-explanatory though, which IMO is a fantastic thing. Reading my configs I would have to use a final flag to show that the message isn't logged again, and missing that the reader would have to inspect the rest of the file to understand if anything else would be done with a particular event.
you can create a destination which has no drivers, e.g. this is valid and works as expected: destination d_null {}; log { source(s_local); destination(d_null); };
I normally only use /dev/null temporarily, when a firewall blocks a destination and I don't just want to leave syslog-ng trying to connect and overflowing the destination buffer for no reason. I modify the destination clause to use /dev/null for a bit.
you can comment out the tcp() destination driver in this case. -- Bazsi
On Tue, Oct 18, 2005 at 05:14:05PM +0200, Balazs Scheidler wrote:
On Mon, 2005-10-17 at 09:18 -0700, Nate Campi wrote:
On Mon, Oct 17, 2005 at 11:57:37AM -0400, Ed Ravin wrote:
But let's go one level deeper - why are the "operators" configuring syslog-ng.conf to write to /dev/null in the first place and thus making this error? It's because the sysadmins want to discard certain log entries. Why not facilitate that by making a special "discard" destination? ... you can create a destination which has no drivers, e.g. this is valid and works as expected:
destination d_null {};
log { source(s_local); destination(d_null); };
Is this documented anywhere? I would have used this a couple of years ago had I known about it. Even so, it would still be good to have a "discard" keyword for readability of the config file and an easy way to learn about the feature when reading the man page (i.e. how do you look up a "null" keyword?).
On Tue, 2005-10-18 at 11:30 -0400, Ed Ravin wrote:
On Tue, Oct 18, 2005 at 05:14:05PM +0200, Balazs Scheidler wrote:
On Mon, 2005-10-17 at 09:18 -0700, Nate Campi wrote:
On Mon, Oct 17, 2005 at 11:57:37AM -0400, Ed Ravin wrote:
But let's go one level deeper - why are the "operators" configuring syslog-ng.conf to write to /dev/null in the first place and thus making this error? It's because the sysadmins want to discard certain log entries. Why not facilitate that by making a special "discard" destination? ... you can create a destination which has no drivers, e.g. this is valid and works as expected:
destination d_null {};
log { source(s_local); destination(d_null); };
Is this documented anywhere? I would have used this a couple of years ago had I known about it. Even so, it would still be good to have a "discard" keyword for readability of the config file and an easy way to learn about the feature when reading the man page (i.e. how do you look up a "null" keyword?).
added a note to the syslog-ng 2.0 documentation, it should be rendered to our website by tomorrow. -- Bazsi
su den 16.10.2005 Klokka 11:39 (-0700) skreiv Nate Campi:
When using /dev/null as a destination on Solaris 8 (sparc) with syslog-ng 1.6.7 the perms of /dev/null get messed up:
$ ls -l /dev/null lrwxrwxrwx 1 root other 27 Apr 19 2003 /dev/null -> ../devices/pseudo/mm@0:null $ ls -l /devices/pseudo/mm@0:null crw-r--r-- 1 root root 13, 2 Oct 16 18:27 /devices/pseudo/mm@0:null
I thought this was addressed at some point, was that only on Linux perhaps?
I'm *sure* I remember doing somesuch on SCO Open Server 5.0 in 1996 (or was it AT&T SVR4?) It's always surprised me pleasantly since on RH Linux, (been using it since 7.2) that I *can't* wipe out /dev/null by writing to it as root. But then again, you can't compare an Alfa Romeo 147 with a 33 boxer. --Tonni -- Mail: tonye@billy.demon.nl http://www.billy.demon.nl
participants (5)
-
Balazs Scheidler
-
Carson Gaspar
-
Ed Ravin
-
Nate Campi
-
Tony Earnshaw