Perl script can't open file owned by root when called from process (Nagios) - linux

I have a VPS with Nagios installed, and I want to use Nagios to monitor the VPS resources in the /proc/user_beancounters file. The file has the following permissions:
-r-------- 1 root root 0 Oct 26 15:53 /proc/user_beancounters
So I downloaded the script from the Nagios Exchange:
https://exchange.nagios.org/directory/Plugins/Operating-Systems/*-Virtual-Environments/OpenVZ/check-beancounters/details
In the instructions it suggests to:
don’t forget to set the s-bit (chmod +s check_UBC.pl)
So, I copied the script over, and set the s-bit, then run it from the terminal as root. It works as expected. I then delete the temp file it created, su into the nagios user, and run the script. It works as expected. I delete the temp file it created, and start up Nagios. It can't read the /proc/user_beancounters file! The exact error I get, helpfully, is "could not read /proc/user_beancounters". This is, I believe, thrown by the line in the Perl script:
if (! open IN, "<", $UBC )
{
print "could not read $UBC\n";
exit $ERRORS{'CRITICAL'};
}
My OS is CentOS release 6.2 (Final).
My first thought is that it is some kind of SELinux voodoo, but there is no indication that SELinux is running on this server. Just in case, I tried the following:
echo 0 > /selinux/enforce
But this made no difference.
For reference, this is my nagios service running:
nagios 12939 0.0 0.0 203652 3404 ? Ssl 15:39 0:00 /usr/sbin/nagios -d /etc/nagios/nagios.cfg
And this is where I've put the Perl script:
-rwsr-sr-x 1 nagios nagios 2934 Oct 26 15:37 check_UBC.pl
Any suggestions as to what else I can try?
PS apologies if this should go in a different SE site - never sure with questions that involve scripts, permissions etc...
UPDATE 1
I created a shell script to see if I could 'emulate' the nagios service. It is extremely simple:
#!/bin/bash
/usr/lib64/nagios/plugins/check_UBC.pl
And now I have the following permissions:
-rwsr-sr-x 1 root root 2934 Oct 26 15:37 check_UBC.pl
-rwxrwxrwx 1 root root 51 Oct 26 19:29 check_UBC.sh
As root:
[root#/usr/lib64/nagios/plugins]$ ./check_UBC.pl
everything is fine..
[root#/usr/lib64/nagios/plugins]$ ./check_UBC.sh
everything is fine..
As nagios:
-bash-4.1$ ./check_UBC.pl
everything is fine..
-bash-4.1$ ./check_UBC.sh
everything is fine..
So still no clue...
UPDATE 2
My nagios command definition:
define command{
command_name check_beancounters
command_line $USER1$/check_UBC.pl
}
And the service definition:
define service{
use local-service
host_name localhost
service_description VPS Beancounters
check_command check_beancounters
}
UPDATE 3
I managed to get it to work, but am not over the moon about giving the nagios user full sudo access with no password. In /etc/sudoers I put this on the last line:
nagios ALL=(ALL:ALL) NOPASSWD: ALL
And then changed my command definition to:
define command{
command_name check_beancounters
command_line sudo $USER1$/check_UBC.pl
}
Apparently recent versions of linux will not respect the +s permission when running an interpreted script, only a binary. So I guess I will have to compile a binary wrapper for the script?
UPDATE 4
As per Joe Young's suggestion, I changed my visudo entry to:
nagios ALL=NOPASSWD: /usr/lib64/nagios/plugins/check_UBC.pl
Which hopefully is relatively harmless!

Try changing the owner of check_UBC.pl to root so that when nagios executes check_UBC.pl the script runs as setuid of it's owner root and not the nagios user.
chown root:root check_UBC.pl
EDIT:
Can you post your command definition that's calling check_UBC.pl?
The last thing I can think of to try is to install the perl-suid module: https://chrisjean.com/fix-setuid-cannot-exec-sperl/
Although, if check_UBC.pl runs from the command line with no problem, I'm not sure what difference it would make.

What would the risk be to change the permissions on /proc/user_beancounters to 444 (read for all?) It only contains a number, correct? Not sure if that particular file "sticks around" after a reboot, or worse, constantly gets replaced as the services are running, so this could be a problem still.
Also, consider trying to test for actual "existence" of the file, before you attempt to read from it. Since we're in /proc directory, things do change, from time to time....
Lastly, you are asking to open the file, but syntactically is it asking to open in a read only mode? You may want to try a system call to simply "cat" the file contents, in your shell script, and see if you get a response.

Related

Root cronjob does not run correctly, user cronjob does

I am trying to run a root cronjob for executing a script.
Here's the cronjob I put into sudo crontab -e:
*/1 * * * * ~/temperature_log/logtemp.sh >> ~/temperature_log/templog.log>&1
The script requires root permission for hddtemp.
Unfortunately, the templog.log file never appears. The syslog says:
Jun 6 13:09:01 user CRON[32433]: (root) CMD (~/temperature_log/logtemp.sh >> ~/temperature_log/templog.log>&1)
Jun 6 13:09:01 user CRON[32426]: (CRON) info (No MTA installed, discarding output)
So apparently, the script IS run, but something goes wrong from there.
Even stranger: If I run a user cron via just crontab -e, the script executes (without root permissions, though, so it is of no use for me) and does write the log file.
How can I make sure that my root crontab works correctly?
I am connecting to this computer via ssh as a user without root permissions, but I do have the root passwort.
EDIT
I changed the program now, I want it to log to syslog via logger. Again, running the script manually works and it logs correctly, but running it from crontab just shows this:
Jun 6 14:27:01 user CRON[1657]: (root) CMD (Jun 6 15:06:01 insystems CRON[25328]: (root) CMD (/bin/sh ~/temperature_log/logtemp.sh)
No information is logged. I added the /dev/null part to get rid of the email warning. I am not planning on installing an email service.
Have you written the script to send email alerts? The warning, "(No MTA installed, discarding output)", happens when a mail service is not installed.
Most Linux distributions have a mail service (including an MTA) installed. Ubuntu doesn't though.
You can install a mail service, postfix for example, to solve this problem.
sudo apt-get install postfix
Also, try providing the full path for the files (The absolute path):
~/temperature_log/logtemp.sh and ~/temperature_log/templog.log
Make sure logtemp.sh has execute permission. If no, then issue command
chmod +x logtemp.sh
My solution was to add the cronjob not to crontab -e but to /etc/crontab. From there, it worked without issues.
I probably made a mistake in the other crontab file, but this solution is okay for me.

pfSense cron job not running or no output

Hope someone can help me out here.
I've written a python script that I want to run under CRON every 5 minutes.
In keeping with the general security practice of least privilege, I:
created a user "custom" to use for custom scripts
created a group "custom" (don't want anything running under nobody to have
access) and;
put the script (monitor) in /home/custom/bin
The shebang in the script is:
#!/usr/bin/env python2.7
The only permission given to user custom is:
Inherited from Name Description Action
User - System: Shell account access Indicates whether the user is able to login for example via SSH.
Running the script with the command /home/custom/bin/monitor from the command line works regardless of the current working directory.
I tried doing cd / first to make sure it wasn't a path issue, and the script ran correctly.
The script writes 2 files on the first run, and subsequent runs append to those files in the directory /home/custom/bin/mondata
I installed the CRON package and created the following entry:
*/5 * * * * custom /home/custom/bin/monitor
(There doesn't seem to be an "Apply Changes", so I'm assuming that I don't need to reboot or do anything to load the changes.)
(The above entry and many others are displayed in the WebGUI, and I know that several of those other cron jobs are running.)
After waiting for enough time for the script to run, I checked for output and there was nothing.
Changing custom to root for testing purposes (Just in case the issue was a permission problem) doesn't fix the problem.
Here are the relevant file permissions:
[2.3.2-RELEASE][custom#local]/home/custom/bin: ls -laR ~
total 52
drwxr-xr-x 4 custom nobody 512 Aug 7 00:14 .
drwxr-xr-x 4 root wheel 512 Jul 27 15:24 ..
drwxr-xr-x 3 custom custom 512 Aug 7 00:14 bin
/home/custom/bin:
total 20
drwxr-xr-x 3 custom custom 512 Aug 7 00:14 .
drwxr-xr-x 4 custom nobody 512 Aug 7 00:14 ..
drwxrwx--- 2 custom custom 512 Aug 7 00:07 mondata <-Script output goes here
-rwxr-xr-x 1 custom custom 4663 Aug 5 22:44 monitor <-The script
/home/custom/bin/mondata:
total 8
drwxrwx--- 2 custom custom 512 Aug 7 00:07 . <-NO OUTPUT! (I deleted the files manually after successful tests)
drwxr-xr-x 3 custom custom 512 Aug 7 00:14 ..
I checked for an error message in: Status / System / Logs / System / General - Nothing found.
I even tried temporarily changing the permissions on /home/custom/bin/mondata to 777 and setting the cron user to root
(totally unacceptable security practice just for testing, but even that didn't work.)
I have no way of knowing if the script is running and the file writes are being denied for some reason, or if the script isn't running at all.
BTW, where is the cron tab? When I run crontab -l as root, I get crontab: no crontab for root, but I KNOW cron jobs are running.
(I have the daily mail report running.)
Any suggestions - even for troubleshooting to know if the script is running would be helpful.
Thanks.
The issue was that python was not executing.
The so called "portable" shebang that worked at the command line -
#!/usr/bin/env python2.7
- DOES NOT WORK from cron.
I created the following file as /home/custom/bin/tcron
#!/usr/bin/env python2.7
import os
os.system('/usr/local/bin/minicron')
When run from the command line, it put the minicron error into the log every time it is run, but did nothing when run from cron.
I changed #!/usr/bin/env python2.7 to #!/usr/local/bin/python2.7, and now it works.
I don't know if this is intentional that #!/usr/bin/env python2.7 doesn't work from cron, but for now I'm not going to worry about it.
I hope by documenting this it might save somebody else the same trouble, and if it's a bug that should be reported, someone who knows how to do that will do so.

Cannot SUDO SU anymore, "no tty present and no askpass program specified"

I have a root server where I disabled login via user root and created another user that is in the sudoer list. So when I want to work on the server I do:
ssh myusername#IP_ADDRESS
On the server:
sudo su
enter my password to get root rights. This worked fine for 6 months now. Today I get this message when doing sudo su:
sudo: no tty present and no askpass program specified
What the hack is happening? What does this error mean and why do I get it?? Without root rights I cannot do so much on the server. Any idea how to fix this?
sudo tries to open /dev/tty for read-write and prints that error if it fails. You've indicated in comments that /dev/tty is missing on your system.
Sudo has an option -S to read the password from standard input instead of /dev/tty. You should be able to run sudo -S to become root.
Regarding how to recover /dev/tty, It's possible that rebooting the server would be sufficient; the system might recreate all devices in /dev during bootup. Alternately, to create a device, you use the mknod command, but you need to know the correct major and minor numbers for the tty device. On an Ubuntu system I have available, I see these entries in /dev:
crw------- 1 root root 5, 1 Apr 16 18:36 console
crw-rw-rw- 1 root tty 5, 2 Sep 24 15:35 ptmx
crw-rw-rw- 1 root tty 5, 0 Sep 24 14:25 tty
In this case, the major number is 5 and the minor number is 0. /dev/console and /dev/ptmx have the same major number. So I'd inspect /dev/console or /dev/ptmx to find the correct major number, then run:
mknod /dev/tty c major 0
where "major" is the correct major number.
After recreating /dev/tty, make sure the permissions are correct:
chmod 666 /dev/tty
It fails, because sudo is trying to prompt on root password and there is no pseudo-tty allocated.
You've to either log-in as root or set-up the following rules in your /etc/sudoers
(or: sudo visudo):
# Members of the admin group may gain root privileges.
%admin ALL=(ALL) NOPASSWD:ALL
Then make sure that your user belongs to admin group (or wheel).
Ideally (safer) it would be to limit root privileges only to specific commands which can be specified as %admin ALL=(ALL) NOPASSWD:/path/to/program
One thing to check is whether the OS thinks that the various processes "have a tty". If you are still having problems, it's probably worth doing this in both the shell within which you run ssh and the shell within which you run sudo. The easy way to check is the command "tty" - if it returns "not a tty", that shell doesn't have a "controlling tty" and cannot open /dev/tty even if it exists in the file system.
Various circumstances can cause a shell to not have been run using a controlling tty, and some of them do not provide any visible warning. E.g., I recently ran into a problem on High Sierra with Emacs shell windows (Cannot open pty under Mac OS High Sierra) -- High Sierra uses a different mechanism for allocating pty's than earlier Mac OS X releases, so if your code isn't reconfigured for it, it will fail to allocate a pty.

Crontab Permission Denied [duplicate]

This question already has answers here:
CronJob not running
(19 answers)
Closed last month.
I'm having problem with crontab when I'm running a script.
My sudo crontab -e looks like this:
05 00 * * * /opt/mcserver/backup.sh
10 00 * * * /opt/mcserver/suspend.sh
05 08 * * * /sbin/shutdown -r +1
11 11 * * * /opt/mcserver/start.sh <--- This isn't working
And the start.sh looks like this:
#!/bin/sh
screen java -d64 -Xincgc -Xmx2048M -jar craftbukkit.jar nogui
and have these permissions (ls -l output)
-rwxr-xr-x 1 eve eve 72 Nov 24 14:17 start.sh
I can run the command from the terminal, either using sudo or not
./start.sh
But it wont start with crontab.
If i do
grep -iR "start.sh" /var/log
I get the following output
/var/log/syslog:Nov 27 11:11:01 eve-desk CRON[5204]: (root) CMD (eve /opt/mcserver/start.sh)
grep: /var/log/btmp: Permission denied
grep: /var/log/lightdm/x-0-greeter.log: Permission denied
grep: /var/log/lightdm/lightdm.log: Permission denied
grep: /var/log/lightdm/x-0.log: Permission denied
So my question is, why isn't it working?
And since my script run without using sudo, I don't necessarily need to put it in sudo crontab?
( and I'm using Ubuntu 12.10 )
Thanks in advance,
Philip
Answer to twalberg's response
1. Changed owner on craftbukkit to root, to see if that fixed the problem.
-rw-r--r-- 1 root root 12084211 Nov 21 02:14 craftbukkit.jar
and also added an explicit cd in my start.sh script as such:
#!/bin/sh
cd /opt/mcserver/
screen java -d64 -Xincgc -Xmx2048M -jar craftbukkit.jar nogui
2. I'm not quite sure what you mean here. Should I use the following path in my start.sh file when i start java?
(output from which java)
/usr/bin/java
3. When my server closes, screen is terminated. Is it a good idea to start screen in "detached mode" anyway?
Still got the same "Permission denied" error.
Problem solved!
By using the proper flag on screen, as below, it is now working as it should!
screen -d -m java -d64 -Xincgc -Xmx2048M -jar craftbukkit.jar nogui
Thanks a lot to those who answered, and especially twalberg!
Here are some things to check:
root obviously has read/execute permissions on start.sh, but what are the permissions on craftbukkit.jar - can root read it? You may also want to add an explicit cd /path/to/where/craftbukkit.jar/is in your start.sh script.
Is java in root's default path within cron? Note that this path is not necessarily the same as the one that you get via sudo, su or directly logging in as root - it's typically much more restricted. Use full path names to both java and craftbukkit.jar to work around that.
Since screen will not start with a terminal available, you may need screen -d -m ... instead. Hopefully, you intend to eventually attach to each screen instance and terminate it later, or you have arranged for it to terminate automatically when the script is done...
The /var/log/syslog entry shows that cron did in fact execute the script, so it must have failed for one of the above reasons (or something else I haven't noticed yet)
The other errors from grep are simply due to the fact your non-root user does not have permission to read those specific files (this is normal, and a good thing).
start.sh is owned by "eve:eve" and your crontab is running as root.
You can solve this by running following command
chown root:root /opt/craftbukkit/start.sh
Your crontab will be running as root though.
Tip: When running bash in crontab always use absolute paths (it will make debugging a lot easier).
The log shows the user has no access to dir " /var/log/", You should set the log files' permition for the cron's owner.

How does Set-user-id bit work on Linux?

I have the following "root-file" with the following contents:
$ cat root-file
#!/bin/bash
echo $EUID
id
Following are the permissions for this file:
$ ls -l root-file
-rwsr-sr-x 1 root root 15 Nov 18 02:20 root-file
Since the set-user-id bit is set for this file, I would expect that on executing this
file, the effective uid would be displayed as 0 even when a non-root user executes it (since set-user-id bit causes the process to be executed with the effective user-id of the owner of the file, which in this case is root). However, instead I get the following output on executing "root-file" from a non-root shell.
$ ./root-file
1000
uid=1000(chanakya) gid=1000(chanakya) groups=1000(chanakya),4(adm),20(dialout),24(cdrom),46(plugdev),105(lpadmin),119(admin),122(sambashare)
This file/or script is not being executed with effective user-id 0. Why is that so?
you cannot use setuid on shell scripts...
if you absolutely need to use setuid checkout http://isptools.sourceforge.net/suid-wrap.html
Normally something like this could also be established using some custom sudo configuration...

Resources