<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">By far the simplest solution would be
to allow group permissions, and add xymon to the group for the
directory. Any other solution is likely to introduce failure modes
that are unexpected, and/or introduce more security implications
than you might think of...<br>
<br>
eg, set the directory group to crash, then add xymon to that
group, and set directory permissions to 750 or similar. Note, this
works perfectly if the directory is currently 700, because you can
create a new group solely for this purpose, so it doesn't give
xymon any additional access other than this folder, and it doesn't
give any other process additional access to the /var/crash folder.<br>
<br>
If the folder is currently 750, and the existing group is used for
other processes/files/folders, then you should assess the security
implications of giving xymon access to all
processes/files/folders.<br>
<br>
Not quite what you wanted, but hopefully it will help<br>
<br>
BTW, do ACL's provide a solution here? Shouldn't ACL's be able to
provide access outside of the simplistic user/group/other scheme?
Does your filesystem/OS support them? Personally, I've never used
them on Linux, so can't comment there.<br>
<br>
Regards,<br>
Adam<br>
<br>
On 27/05/14 10:01, Jeremy Laidman wrote:<br>
</div>
<blockquote
cite="mid:CAAnki7D4JdKfC2W-g_hTP=Hm19E_ySYN98MagDu1vu=n4hkTQg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 23 May 2014 11:21, Vernon Everett
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:everett.vernon@gmail.com" target="_blank">everett.vernon@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Anybody know of a way to give Xymon elevated access
permissions when it stats files it's checking?<br>
</div>
<div>
I would prefer not to change the directory permissions
if I can avoid it.</div>
</blockquote>
</div>
<br>
Apart from running Xymon as root, I don't think you can do
this.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">
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:</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">
#!/bin/sh</div>
<div class="gmail_extra">NEWDIR=/var/crash-monitor # must be
same filesystem as /var/crash</div>
<div class="gmail_extra">rm -rf "$NEWDIR" || exit 1<br>
</div>
<div class="gmail_extra">mkdir -f "$NEWDIR" || exit 1</div>
<div class="gmail_extra">chown root:xymon "$NEWDIR"</div>
<div class="gmail_extra">chmod 550 "$NEWDIR"</div>
<div class="gmail_extra">cd /var/crash || exit 1</div>
<div class="gmail_extra">for file in *; do ln "$f" "$NEWDIR/$f";
done<br>
</div>
<div class="gmail_extra">ls "$NEWDIR"/*</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">This creates a replica of /var/crash/
that Xymon can read (and stat the files), without changing the
original dir perms and ownership.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">This is run from within the "file:"
backticks (using sudo), and so it produces the hardlink names
as its output.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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. <br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">*untested</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">j</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
Adam Goryachev
Website Managers
<a class="moz-txt-link-abbreviated" href="http://www.websitemanagers.com.au">www.websitemanagers.com.au</a></div>
</body>
</html>