Bill Houle wrote:
>
> > What happens with majorcool if it is installed to run as the same
> > user and group as majordomo? Whouldn't this save tons of headaches?
>
> Good question. Answer: it already does.
>
> Keep in mind that MajorCool is just a bunch of Perl scripts. There
> is no compiled code. In addition, there is no reliance on suidperl.
> So how are permissions enforced? Simple: the sole purpose of the
> CGI program (placed in the /cgi-bin directory) is to invoke the
> workhorse Perl program (placed in the Majordomo $bindir) VIA THE
> MAJORDOMO WRAPPER PROGRAM.
>
> Thus, MajorCool only works as well as Majordomo itself. There are
> (unfortunately) several ways to make Majordomo work without having
> the permissions setup exactly as the designers originally intended.
> We often see "Majordomo is working fine, but MajorCool is broken".
> Is this because MajorCool permissions are wrong? No, it probably
> means that Majordomo is working, just not quite as perfectly as it
> could be.
>
> Things like MajorCool and stepped-up sendmail security tend to
> point out the minor little flaws in Majordomo installations that
> otherwise might go unheeded. Treat the disease, not the symptoms.
> Always look at the setuid "wrapper" program and the permissions
> on the Majordomo tree as a first approach to problem solving.
>
> --bill
It sounds as if someone is a little touchy (defensive) of majorcool.
The original question to the list was (still) in the subject of this
message. User 99 was "nobody" not "majordomo". In this case, it
does not matter what cgi is running, if it is not majordomo (or root),
it can't write to the majordomo owned files. This does not indicate
a poorly installed majordomo, but a misconfigured cgi.
Dan Liston
Follow-Ups:
|
|
