Not quite sure why you think I am being touchy. You asked why
MajorCool didn't run a certain way, and I explained that it does.
As for the original question, I thought I was being clear and
direct about how to diagnose such problems. I guess I need to
spell it out:
"shlock" is a Majordomo function being called via "majorcool.pl"
under the permissions established by the Majordomo "wrapper". It
is complaining that it is unable to write to the /usr/majordomo
directory because the directory is owned by "majordom" yet the
effective uid is "nobody". This would be because the permissions
established by wrapper (when compared to the directory itself)
are incorrect: user-ids do not match, wrapper not SUID, filesystem
is NFS'd as "nosuid", or any number of other wrapper-related reasons.
All I'm saying is: it's most likely "wrapper" and the permissions
on the tree that are the problem. If that's being defensive about
MajorCool, so be it.
--bill
> 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
>
References:
|
|
