RCS and perms (WAS: Re: non-root postfix admin; sudo -vs- super)
Hi Craig, On Fri, 29 Jun 2001, Craig Sanders wrote: [...] the 660 permissions on the /etc/radius/radius.users file allow the admin group to edit it and check it in to RCS. Could you elaborate on this please? I started by ading a group mailadm, the theory being that all the relevant files would be modifiable by this group and all the people who should be modifying such files would have suplementary membership of this group. What I can't seem to get right is a simple scheme so that they can't (accidently ;-) fiddle with the RCS/ files. i.e. it seems to need to be like this: neale@foo:/usr/local/mailadm/etc$ ls -l total 11 drwxrwsr-x2 root mailadm 1024 Jul 4 18:31 RCS -r--r--r--1 nealemailadm 10069 Jul 4 18:31 relay_domains Or is this yet another job for sudo? OTOH, perhaps I'm being overly paranoid here? Thanks, Neale. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-root postfix admin; sudo -vs- super
Thank you Craing and Ilya - I now see where I was approaching this from the wrong direction. The overall framework I'm trying to get happening is to use a supplementary group for the users and files to be maintained outside /etc/postfix and some simple glue-scripts to move the modified files into place with the appropriate ownership, mode etc. That should be simple enough to keep (relatively) secure. The point about the dangers of allowing untrusted users to tweak things like /etc/postfix/master.cf is a good one too - but that shouldn't be a problem as I'm targetting things like virtual users, relaydomains etc. Regards, Neale.
non-root postfix admin; sudo -vs- super
Greetings all, With particular relevance to potato... I see that by default the files in /etc/postfix are owner: group root:root. This obviously doesn't lend itself to the contents thereof being admin'ed by admins who don't otherwise enjoy the total freedom of the system (nor is it best for those of us who like to spend as little time as is necessary as root). There would seem to be (at least) three solutions: * different owner:group and mode * 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? Any alternate solutions? Thanks, Neale. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-root postfix admin; sudo -vs- super
NB I see that by default the files in /etc/postfix are owner: group NB root:root. This obviously doesn't lend itself to the contents thereof NB being admin'ed by admins who don't otherwise enjoy the total freedom of NB the system (nor is it best for those of us who like to spend as little NB time as is necessary as root). NB There would seem to be (at least) three solutions: NB * different owner:group and mode NB * use sudo -or- super to allow postfix admins to do what is necessary. NB What do people see as the relative merits of these? NB What are the differences between sudo and super in these kind of NB circumstances? NB Any alternate solutions? I want to warn you that if you give someone ability to change postfix configs you can open huge security hole. For example if someone can edit /etc/postfix/master.cf he/she effectively has root because he/she can setup pseudo transport which will launch any script under any uid. And there are exist other dangerous places in postfix configs. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
non-root postfix admin; sudo -vs- super
Greetings all, With particular relevance to potato... I see that by default the files in /etc/postfix are owner: group root:root. This obviously doesn't lend itself to the contents thereof being admin'ed by admins who don't otherwise enjoy the total freedom of the system (nor is it best for those of us who like to spend as little time as is necessary as root). There would seem to be (at least) three solutions: * different owner:group and mode * 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? Any alternate solutions? Thanks, Neale.
Re: non-root postfix admin; sudo -vs- super
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 QD 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 [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: non-root postfix admin; sudo -vs- super
NB I see that by default the files in /etc/postfix are owner: group NB root:root. This obviously doesn't lend itself to the contents thereof NB being admin'ed by admins who don't otherwise enjoy the total freedom of NB the system (nor is it best for those of us who like to spend as little NB time as is necessary as root). NB There would seem to be (at least) three solutions: NB * different owner:group and mode NB * use sudo -or- super to allow postfix admins to do what is necessary. NB What do people see as the relative merits of these? NB What are the differences between sudo and super in these kind of NB circumstances? NB Any alternate solutions? I want to warn you that if you give someone ability to change postfix configs you can open huge security hole. For example if someone can edit /etc/postfix/master.cf he/she effectively has root because he/she can setup pseudo transport which will launch any script under any uid. And there are exist other dangerous places in postfix configs. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
