Potential bug in FILE analysis 🔗 link

On 22/05/14 15:40, Vernon Everett wrote:

Hi all

Not sure if this really classifies as a bug or not.
I am inclined to think it is.

In clientlocal.cfg, I have
[sunos]
file:`/usr/bin/sudo /usr/bin/find /var/crash/ -type f 2> /dev/null`

And this finds 2 files.
/var/crash/bounds
/var/crash/vmdump.0
So far so good.

However, /var/crash/ is a symlink to /var/share/crash/
And /var/share/crash has permissions or 700
So Xymon can determine there is a file, but cannot collect any metadata on the file, since it cannot stat the files in /var/share/crash/

In analysis.cfg I have this line (with appropriate HOST= value, of course)
FILE    %^/var/cores/.*         NOEXIST         red
When I go to the "files" page, I see the file names there.
Clicking on the file names, I get this info.
[file:/var/crash/vmdump.0]
ERROR: Permission denied

But no red status appears on the test.
Testing, using a similar directory structure, where Xymon can stat the files, does give a red status.

I can understand that Xymon can't give any info on the file because of permissions, but in this case, all I care about is that the file exists, which Xymon has determined.
That should trigger a red status.

Using Xymon 4.3.10

Regards
Vernon


-- 
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

-- 

On 23 May 2014 07:18, Adam Goryachev <user-92fd6827f6ae@xymon.invalid>wrote:

 OK, so you are using sudo to generate a list of filenames, so xymon can
read the list of filenames you want to monitor (the same as if you just
hardcoded /var/crash/bounds and /var/crash/vmdump.0 into the
clientlocal.cfg file.

However, when xymon tries to look at the details for the file you have
asked it to check, it can't determine *any* information about the file, not
even whether it exists or not, because it doesn't have sufficient
privileges. You would need xymon to have sudo power to check the file as
well, (not sure if that would be feasible) or else to add at least rx
permissions for xymon to be able to provide information:

ls -ld test
drwx------ 2 root root 4096 May 23 09:10 test
agoryachev at it-desktop:/tmp$ ls -l test
ls: cannot open directory test: Permission denied
agoryachev at it-desktop:/tmp$ sudo chmod +r test
root at it-desktop:/tmp# exit
agoryachev at it-desktop:/tmp$ ls -l test
ls: cannot access test/two: Permission denied
ls: cannot access test/one: Permission denied
total 0
-????????? ? ? ? ?            ? one
-????????? ? ? ? ?            ? two
agoryachev at it-desktop:/tmp$ ls -l test/one
ls: cannot access test/one: Permission denied
agoryachev at it-desktop:/tmp$ sudo chmod +x test
root at it-desktop:/tmp# exit
agoryachev at it-desktop:/tmp$ ls -l test
total 0
-rw-r--r-- 1 root root 0 May 23 09:10 one
-rw-r--r-- 1 root root 0 May 23 09:10 two

So you can read the directory contents with +r, but you need +x to be able
to stat those directory entries. At least, that applies on my Linux
workstation, it may depend on your OS/etc.

Regards,
Adam


On 22/05/14 15:40, Vernon Everett wrote:

        Hi all

 Not sure if this really classifies as a bug or not.
 I am inclined to think it is.

 In clientlocal.cfg, I have
 [sunos]
file:`/usr/bin/sudo /usr/bin/find /var/crash/ -type f 2> /dev/null`

 And this finds 2 files.
 /var/crash/bounds
 /var/crash/vmdump.0
 So far so good.

 However, /var/crash/ is a symlink to /var/share/crash/
 And /var/share/crash has permissions or 700
 So Xymon can determine there is a file, but cannot collect any metadata
on the file, since it cannot stat the files in /var/share/crash/

 In analysis.cfg I have this line (with appropriate HOST= value, of
course)
 FILE    %^/var/cores/.*         NOEXIST         red
When I go to the "files" page, I see the file names there.
Clicking on the file names, I get this info.
[file:/var/crash/vmdump.0]
ERROR: Permission denied

 But no red status appears on the test.
 Testing, using a similar directory structure, where Xymon can stat the
files, does give a red status.

 I can understand that Xymon can't give any info on the file because of
permissions, but in this case, all I care about is that the file exists,
which Xymon has determined.
That should trigger a red status.

 Using Xymon 4.3.10

 Regards
Vernon


--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

-- 
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

On Thu, May 22, 2014 at 9:21 PM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid>wrote:

...the same as if you just hardcoded /var/crash/bounds and
/var/crash/vmdump.0....

As soon as I read this, I had my "D'oh!" moment.
Of course, the "sudo find" only generates the list of files to check.
So not a bug. A permissions error.

Anybody know of a way to give Xymon elevated access permissions when it
stats files it's checking?
I would prefer not to change the directory permissions if I can avoid it.

Thanks
Vernon


On 23 May 2014 07:18, Adam Goryachev <user-92fd6827f6ae@xymon.invalid>wrote:

 OK, so you are using sudo to generate a list of filenames, so xymon can
read the list of filenames you want to monitor (the same as if you just
hardcoded /var/crash/bounds and /var/crash/vmdump.0 into the
clientlocal.cfg file.

However, when xymon tries to look at the details for the file you have
asked it to check, it can't determine *any* information about the file, not
even whether it exists or not, because it doesn't have sufficient
privileges. You would need xymon to have sudo power to check the file as
well, (not sure if that would be feasible) or else to add at least rx
permissions for xymon to be able to provide information:

ls -ld test
drwx------ 2 root root 4096 May 23 09:10 test
agoryachev at it-desktop:/tmp$ ls -l test
ls: cannot open directory test: Permission denied
agoryachev at it-desktop:/tmp$ sudo chmod +r test
root at it-desktop:/tmp# exit
agoryachev at it-desktop:/tmp$ ls -l test
ls: cannot access test/two: Permission denied
ls: cannot access test/one: Permission denied
total 0
-????????? ? ? ? ?            ? one
-????????? ? ? ? ?            ? two
agoryachev at it-desktop:/tmp$ ls -l test/one
ls: cannot access test/one: Permission denied
agoryachev at it-desktop:/tmp$ sudo chmod +x test
root at it-desktop:/tmp# exit
agoryachev at it-desktop:/tmp$ ls -l test
total 0
-rw-r--r-- 1 root root 0 May 23 09:10 one
-rw-r--r-- 1 root root 0 May 23 09:10 two

So you can read the directory contents with +r, but you need +x to be
able to stat those directory entries. At least, that applies on my Linux
workstation, it may depend on your OS/etc.

Regards,
Adam


On 22/05/14 15:40, Vernon Everett wrote:

        Hi all

 Not sure if this really classifies as a bug or not.
 I am inclined to think it is.

 In clientlocal.cfg, I have
 [sunos]
file:`/usr/bin/sudo /usr/bin/find /var/crash/ -type f 2> /dev/null`

 And this finds 2 files.
 /var/crash/bounds
 /var/crash/vmdump.0
 So far so good.

 However, /var/crash/ is a symlink to /var/share/crash/
 And /var/share/crash has permissions or 700
 So Xymon can determine there is a file, but cannot collect any metadata
on the file, since it cannot stat the files in /var/share/crash/

 In analysis.cfg I have this line (with appropriate HOST= value, of
course)
 FILE    %^/var/cores/.*         NOEXIST         red
When I go to the "files" page, I see the file names there.
Clicking on the file names, I get this info.
[file:/var/crash/vmdump.0]
ERROR: Permission denied

 But no red status appears on the test.
 Testing, using a similar directory structure, where Xymon can stat the
files, does give a red status.

 I can understand that Xymon can't give any info on the file because of
permissions, but in this case, all I care about is that the file exists,
which Xymon has determined.
That should trigger a red status.

 Using Xymon 4.3.10

 Regards
Vernon


--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton


Xymon mailing user-d459c9d661b6@xymon.invalid


--
Adam Goryachev Website Managers www.websitemanagers.com.au

--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

On 23 May 2014 09:31, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid> wrote:

Maybe a cron job running as root to do the stat and drop the results into
a file in Xymon's tmp directory, where an ext script can read and report?
 The root script could read the list of files from the Xymon client's
local.cfg.

Ralph Mitchell


On Thu, May 22, 2014 at 9:21 PM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid>wrote:

...the same as if you just hardcoded /var/crash/bounds and
/var/crash/vmdump.0....

As soon as I read this, I had my "D'oh!" moment.
Of course, the "sudo find" only generates the list of files to check.
So not a bug. A permissions error.

Anybody know of a way to give Xymon elevated access permissions when it
stats files it's checking?
I would prefer not to change the directory permissions if I can avoid it.

Thanks
Vernon

wrote:

 OK, so you are using sudo to generate a list of filenames, so xymon
can read the list of filenames you want to monitor (the same as if you just
hardcoded /var/crash/bounds and /var/crash/vmdump.0 into the
clientlocal.cfg file.

However, when xymon tries to look at the details for the file you have
asked it to check, it can't determine *any* information about the file, not
even whether it exists or not, because it doesn't have sufficient
privileges. You would need xymon to have sudo power to check the file as
well, (not sure if that would be feasible) or else to add at least rx
permissions for xymon to be able to provide information:

ls -ld test
drwx------ 2 root root 4096 May 23 09:10 test
agoryachev at it-desktop:/tmp$ ls -l test
ls: cannot open directory test: Permission denied
agoryachev at it-desktop:/tmp$ sudo chmod +r test
root at it-desktop:/tmp# exit
agoryachev at it-desktop:/tmp$ ls -l test
ls: cannot access test/two: Permission denied
ls: cannot access test/one: Permission denied
total 0
-????????? ? ? ? ?            ? one
-????????? ? ? ? ?            ? two
agoryachev at it-desktop:/tmp$ ls -l test/one
ls: cannot access test/one: Permission denied
agoryachev at it-desktop:/tmp$ sudo chmod +x test
root at it-desktop:/tmp# exit
agoryachev at it-desktop:/tmp$ ls -l test
total 0
-rw-r--r-- 1 root root 0 May 23 09:10 one
-rw-r--r-- 1 root root 0 May 23 09:10 two

So you can read the directory contents with +r, but you need +x to be
able to stat those directory entries. At least, that applies on my Linux
workstation, it may depend on your OS/etc.

Regards,
Adam


On 22/05/14 15:40, Vernon Everett wrote:

        Hi all

 Not sure if this really classifies as a bug or not.
 I am inclined to think it is.

 In clientlocal.cfg, I have
 [sunos]
file:`/usr/bin/sudo /usr/bin/find /var/crash/ -type f 2> /dev/null`

 And this finds 2 files.
 /var/crash/bounds
 /var/crash/vmdump.0
 So far so good.

 However, /var/crash/ is a symlink to /var/share/crash/
 And /var/share/crash has permissions or 700
 So Xymon can determine there is a file, but cannot collect any metadata
on the file, since it cannot stat the files in /var/share/crash/

 In analysis.cfg I have this line (with appropriate HOST= value, of
course)
 FILE    %^/var/cores/.*         NOEXIST         red
When I go to the "files" page, I see the file names there.
Clicking on the file names, I get this info.
[file:/var/crash/vmdump.0]
ERROR: Permission denied

 But no red status appears on the test.
 Testing, using a similar directory structure, where Xymon can stat the
files, does give a red status.

 I can understand that Xymon can't give any info on the file because of
permissions, but in this case, all I care about is that the file exists,
which Xymon has determined.
That should trigger a red status.

 Using Xymon 4.3.10

 Regards
Vernon


--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton


Xymon mailing user-d459c9d661b6@xymon.invalid


--
Adam Goryachev Website Managers www.websitemanagers.com.au

--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

-- 
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

Ralph Mitchell


On Thu, May 22, 2014 at 9:44 PM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid>wrote:

That will work for sure, but it just sounds like reinventing the wheel so
I can take the long way round.

On 23 May 2014 09:31, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid> wrote:

Maybe a cron job running as root to do the stat and drop the results into
a file in Xymon's tmp directory, where an ext script can read and report?
 The root script could read the list of files from the Xymon client's
local.cfg.

Ralph Mitchell

wrote:

...the same as if you just hardcoded /var/crash/bounds and
/var/crash/vmdump.0....

As soon as I read this, I had my "D'oh!" moment.
Of course, the "sudo find" only generates the list of files to check.
So not a bug. A permissions error.

Anybody know of a way to give Xymon elevated access permissions when it
stats files it's checking?
I would prefer not to change the directory permissions if I can avoid it.

Thanks
Vernon


On 23 May 2014 07:18, Adam Goryachev <
user-92fd6827f6ae@xymon.invalid> wrote:

 OK, so you are using sudo to generate a list of filenames, so xymon
can read the list of filenames you want to monitor (the same as if you just
hardcoded /var/crash/bounds and /var/crash/vmdump.0 into the
clientlocal.cfg file.

However, when xymon tries to look at the details for the file you have
asked it to check, it can't determine *any* information about the file, not
even whether it exists or not, because it doesn't have sufficient
privileges. You would need xymon to have sudo power to check the file as
well, (not sure if that would be feasible) or else to add at least rx
permissions for xymon to be able to provide information:

ls -ld test
drwx------ 2 root root 4096 May 23 09:10 test
agoryachev at it-desktop:/tmp$ ls -l test
ls: cannot open directory test: Permission denied
agoryachev at it-desktop:/tmp$ sudo chmod +r test
root at it-desktop:/tmp# exit
agoryachev at it-desktop:/tmp$ ls -l test
ls: cannot access test/two: Permission denied
ls: cannot access test/one: Permission denied
total 0
-????????? ? ? ? ?            ? one
-????????? ? ? ? ?            ? two
agoryachev at it-desktop:/tmp$ ls -l test/one
ls: cannot access test/one: Permission denied
agoryachev at it-desktop:/tmp$ sudo chmod +x test
root at it-desktop:/tmp# exit
agoryachev at it-desktop:/tmp$ ls -l test
total 0
-rw-r--r-- 1 root root 0 May 23 09:10 one
-rw-r--r-- 1 root root 0 May 23 09:10 two

So you can read the directory contents with +r, but you need +x to be
able to stat those directory entries. At least, that applies on my Linux
workstation, it may depend on your OS/etc.

Regards,
Adam


On 22/05/14 15:40, Vernon Everett wrote:

        Hi all

 Not sure if this really classifies as a bug or not.
 I am inclined to think it is.

 In clientlocal.cfg, I have
 [sunos]
file:`/usr/bin/sudo /usr/bin/find /var/crash/ -type f 2> /dev/null`

 And this finds 2 files.
 /var/crash/bounds
 /var/crash/vmdump.0
 So far so good.

 However, /var/crash/ is a symlink to /var/share/crash/
 And /var/share/crash has permissions or 700
 So Xymon can determine there is a file, but cannot collect any
metadata on the file, since it cannot stat the files in
/var/share/crash/

 In analysis.cfg I have this line (with appropriate HOST= value, of
course)
 FILE    %^/var/cores/.*         NOEXIST         red
When I go to the "files" page, I see the file names there.
Clicking on the file names, I get this info.
[file:/var/crash/vmdump.0]
ERROR: Permission denied

 But no red status appears on the test.
 Testing, using a similar directory structure, where Xymon can stat the
files, does give a red status.

 I can understand that Xymon can't give any info on the file because of
permissions, but in this case, all I care about is that the file exists,
which Xymon has determined.
That should trigger a red status.

 Using Xymon 4.3.10

 Regards
Vernon


--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton


Xymon mailing user-d459c9d661b6@xymon.invalid


--
Adam Goryachev Website Managers www.websitemanagers.com.au

--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

On 05/22/14 21:21, Vernon Everett wrote:

...the same as if you just hardcoded /var/crash/bounds and /var/crash/vmdump.0....

As soon as I read this, I had my "D'oh!" moment.
Of course, the "sudo find" only generates the list of files to check.
So not a bug. A permissions error.

Anybody know of a way to give Xymon elevated access permissions when it stats
files it's checking?
I would prefer not to change the directory permissions if I can avoid it.

Anybody know of a way to give Xymon elevated access permissions when it
stats files it's checking?
I would prefer not to change the directory permissions if I can avoid it.

Thanks
Vernon

On 23 May 2014 11:21, Vernon Everett <user-b3f8dacb72c8@xymon.invalid> wrote:

Anybody know of a way to give Xymon elevated access permissions when it
stats files it's checking?
I would prefer not to change the directory permissions if I can avoid it.

On 27/05/14 10:01, Jeremy Laidman wrote:

On 23 May 2014 11:21, Vernon Everett <user-b3f8dacb72c8@xymon.invalid <mailto:user-b3f8dacb72c8@xymon.invalid>> wrote:

    Anybody know of a way to give Xymon elevated access permissions
    when it stats files it's checking?
    I would prefer not to change the directory permissions if I can
    avoid it.


Apart from running Xymon as root, I don't think you can do this.

An alternative* might be to have a script that creates hard links for all files in /var/crash/ into another directory that the xymon user can read.  For example:

#!/bin/sh
NEWDIR=/var/crash-monitor  # must be same filesystem as /var/crash
rm -rf "$NEWDIR" || exit 1
mkdir -f "$NEWDIR" || exit 1
chown root:xymon "$NEWDIR"
chmod 550 "$NEWDIR"
cd /var/crash || exit 1
for file in *; do ln "$f" "$NEWDIR/$f"; done
ls "$NEWDIR"/*

This creates a replica of /var/crash/ that Xymon can read (and stat the files), without changing the original dir perms and ownership.

This is run from within the "file:" backticks (using sudo), and so it produces the hardlink names as its output.

You could have run this script from root's cron, but you'd have a race condition where sometimes Xymon will look at the replica directory after it has been created but before the hard links have been created.

*untested

j

--