Dr. Richard Edward Horner (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} mechanyx) wrote,@ 2008-06-24 12:22:00 |
|
Probably about 2 ppl will understand why this is funny/alarming
I come across a lot of retarded shit everyday in computing. Admittedly, computing is REALLY phuqqing hard and it's unreasonable to expect everyone to be 100% on 100% of the time so some dumb shit is inevitably going to make it into the system. Well, nagios has a broken check_mailq plugin which ALWAYS tells you that the mailq is OK when run with the default settings because it doesn't correctly parse the output from mailq when run as a non-privileged user which is there to tell you that mailq has to be run as a privileged user. So, I thought of three solutions:
1) Add the nagios user to the mail group and then change the permissions on /var/spool.
2) Setup the nagios user to be sudo NOPASSWD for the mailq command or the check_mailq.
3) Make mailq setuid root.
1 may not be the best idea because a process may "fix" the permissions on /var/spool.
2 is kindof a pain in the ass because you have to alter how nagios is calling the plugin.
3 is super easy. It's just a single command:
# chmod u+s `which mailq`
Check out what I found though. This is on CentOS 4.5:
$ ls -lA /usr/bin/mailq
lrwxrwxrwx 1 root root 27 Sep 18 2007 /usr/bin/mailq -> /etc/alternatives/mta-mailq
$ ls -lA /etc/alternatives/mta-mailq
lrwxrwxrwx 1 root root 23 Sep 18 2007 /etc/alternatives/mta-mailq -> /usr/bin/mailq.sendmail
$ ls -lA /usr/bin/mailq.sendmail
lrwxrwxrwx 1 root root 23 Sep 18 2007 /usr/bin/mailq.sendmail -> ../../usr/sbin/sendmail
$ ls -lA /usr/sbin/sendmail
lrwxrwxrwx 1 root root 21 Sep 18 2007 /usr/sbin/sendmail -> /etc/alternatives/mta
$ ls -lA /etc/alternatives/mta
lrwxrwxrwx 1 root root 27 Sep 18 2007 /etc/alternatives/mta -> /usr/sbin/sendmail.sendmail
$ ls -lA /usr/sbin/sendmail.sendmail
-rwsr-sr-x 1 root smmsp 746328 May 2 2007 /usr/sbin/sendmail.sendmail
Yeah, uhh, as if that symlinking isn't amusing enough, don't set mailq as setuid root :)
Also, for the developers reading this, I've always hated when a single command has its behavior multiplexed by looking at its call method. /etc/init.d/net.eth0 anyone? Isn't that practice discouraged by the GNU coding standards? Well, if you need a real world reason as to why you shouldn't be doing that in your programs, here you go. Obfuscating what program actually being called might lead to someone accidentally setting their MTA to setuid root because they think they're only chmodding some helper program.
I come across a lot of retarded shit everyday in computing. Admittedly, computing is REALLY phuqqing hard and it's unreasonable to expect everyone to be 100% on 100% of the time so some dumb shit is inevitably going to make it into the system. Well, nagios has a broken check_mailq plugin which ALWAYS tells you that the mailq is OK when run with the default settings because it doesn't correctly parse the output from mailq when run as a non-privileged user which is there to tell you that mailq has to be run as a privileged user. So, I thought of three solutions:
1) Add the nagios user to the mail group and then change the permissions on /var/spool.
2) Setup the nagios user to be sudo NOPASSWD for the mailq command or the check_mailq.
3) Make mailq setuid root.
1 may not be the best idea because a process may "fix" the permissions on /var/spool.
2 is kindof a pain in the ass because you have to alter how nagios is calling the plugin.
3 is super easy. It's just a single command:
# chmod u+s `which mailq`
Check out what I found though. This is on CentOS 4.5:
$ ls -lA /usr/bin/mailq
lrwxrwxrwx 1 root root 27 Sep 18 2007 /usr/bin/mailq -> /etc/alternatives/mta-mailq
$ ls -lA /etc/alternatives/mta-mailq
lrwxrwxrwx 1 root root 23 Sep 18 2007 /etc/alternatives/mta-mailq -> /usr/bin/mailq.sendmail
$ ls -lA /usr/bin/mailq.sendmail
lrwxrwxrwx 1 root root 23 Sep 18 2007 /usr/bin/mailq.sendmail -> ../../usr/sbin/sendmail
$ ls -lA /usr/sbin/sendmail
lrwxrwxrwx 1 root root 21 Sep 18 2007 /usr/sbin/sendmail -> /etc/alternatives/mta
$ ls -lA /etc/alternatives/mta
lrwxrwxrwx 1 root root 27 Sep 18 2007 /etc/alternatives/mta -> /usr/sbin/sendmail.sendmail
$ ls -lA /usr/sbin/sendmail.sendmail
-rwsr-sr-x 1 root smmsp 746328 May 2 2007 /usr/sbin/sendmail.sendmail
Yeah, uhh, as if that symlinking isn't amusing enough, don't set mailq as setuid root :)
Also, for the developers reading this, I've always hated when a single command has its behavior multiplexed by looking at its call method. /etc/init.d/net.eth0 anyone? Isn't that practice discouraged by the GNU coding standards? Well, if you need a real world reason as to why you shouldn't be doing that in your programs, here you go. Obfuscating what program actually being called might lead to someone accidentally setting their MTA to setuid root because they think they're only chmodding some helper program.
