Re: non-root postfix admin; sudo -vs- super

[Craig Sanders <cas@taz.net.au>]

On Fri, Jun 29, 2001 at 05:07:46PM +1000, Neale Banks wrote:
> * use sudo -or- super to allow postfix admins to do what is necessary.
> 
> What do people see as the relative merits of these?
> 
> What are the differences between sudo and super in these kind of
> circumstances?

i use sudo. it's easy to understand and easy to configure. it works well
enough that i've never had any need to examine super closely.

try both, see which one you like most.



i write little wrapper scripts like the following:

---cut here---/usr/local/sbin/editradius---cut here---
#! /bin/bash

# this one is run by any user in group admin

cd /etc/radius
co -l radius.users
sensible-editor radius.users
sudo /usr/local/sbin/makeradius
ci -u radius.users
---cut here---

---cut here---/usr/local/sbin/makeradius---cut here---
#! /bin/bash

# this one is run with sudo from editradius

cd /etc/radius
/usr/bin/make -f ./Makefile
---cut here---

the 660 permissions on the /etc/radius/radius.users file allow the admin
group to edit it and check it in to RCS.

the Makefile in /etc/radius then generates the real cistron users file
and runs /etc/init.d/radiusd reload (and does some other stuff like
rsyncing various files to other machines as a Q&D backup)

/etc/sudoers is configured to allow admin staff to run
/usr/local/sbin/makeradius as root.


the point of doing it this way is to give the absolute minimum
priviledges required to do the job. it would have been much easier to
just make the editradius script sudo-able, but that would have affected
the user-id that the changes were attributed to by RCS. even worse, it
would have given them an editor such as vi running as root (may as well
give them root).

btw, in any script that runs as root it's important to specify the full
paths to binaries (alternatively, explicitly set the PATH to a known
safe value) so that the users can't play evil tricks with the PATH.



this isn't specific to the postfix question you asked, but these
principles can be applied to any setuid root tasks. never let a user
run an editor as root. if you can't change the perms on the file then
write a wrapper script to lock the file and copy it, and another wrapper
to copy it back and unlock it. configure sudo to allow those wrapper
scripts to be run as root.


craig

-- 
craig sanders <cas@taz.net.au>

Fabricati Diem, PVNC.
 -- motto of the Ankh-Morpork City Watch