Jason L Tibbitts <tibbs@math.uh.edu> writes:
>>>>>> "RA" == Russ Allbery <rra@stanford.edu> writes:
> RA> The documentation is *really* sparse, and it's very inobvious where
> RA> things get put and what things are called.
> Would an explanation of the directory structure help here, or are you
> looking for something else?
I think that's most of what I was missing, along with the additional
documentation stuff that has been mentioned as being under development.
(The additional documentation of config variables would definitely be
useful.)
> RA> First off, when installing on a qmail system, there's no need at all
> RA> for the setuid wrappers,
> Nobody who has ever commented on the qmail stuff has _ever_ mentioned
> this. (Perhaps because other think that they are needed, perhaps.)
I'm sorry, I thought that I had early on. The issues are discussed
somewhat extensively in the Majordomo with qmail FAQ, although that's for
Majordomo version 1.
> Why aren't the wrappers needed? Do you just run Majordomo as the same
> user that runs your mail system (doesn't seem to be the best thing,
> security-wise, to me) or does qmail change users itself?
The latter. setuid wrappers are needed in Majordomo in order to work
around a design decision sendmail, basically. sendmail does a setuid() to
daemon before executing any programs invoked from the system-wide alias
maps, which makes some degree of sense from a security perspective and in
a world where a lot of deliveries aren't being controlled by users, but it
means that if you want a delivery to be controlled by a specific user you
have to become root again so that you can do a setuid() to the appropriate
user.
Postfix, IIRC, gets around this by allowing for alias maps owned by a
specific user and doing a setuid to that user when delivering to programs
in those maps. qmail essentially does the same, but uses .qmail files.
In my case, I have a virtual domain lists.eyrie.org, which I associate
with the lists user. qmail will then by default setuid() to lists and
then delivery mail as controlled by the .qmail files in lists's home
directory (provided that lists owns its own home directory; if it doesn't,
you have to use the qmail-users mechanism to override).
> RA> but while the rest of Majordomo 2 runs fine without them, the
> RA> installation fails because mj_shell requires that it be running as
> RA> the list user.
> Well, it has to; if it runs as any regular user then it just isn't going
> to be able to get any access.
*nod* It makes some sense, it just took me a bit to figure out how to let
the installation complete. Running make install as root, letting
postinstall fail, and then giving lists a valid shell and running:
su lists -c 'make postinstall'
worked.
> Not yet implemented. Sorry; the qmail stuff is half done and I got a
> bunch of conflicting information about it (and now I'm getting more) so
> I had to stop working on it. (I got far enough to write the
> instructions, but not all of the code.)
Ah, okay. No apologies needed; I knew I was working out of a CVS snapshot
and things may not necessarily be consistent. After looking at this under
qmail 1.03, I think the idea of using DEFAULT is the right way to go.
After I added a |/path/to/mj_email -Q -d lists.eyrie.org to .qmail-default
by hand, it worked great except for the problem with sending outgoing
mail.
> RA> I spent a lot of time trying to figure out how to set an info
> RA> message before realizing that newinfo *did* still work despite all
> RA> of this funky file put management stuff. For some reason, that
> RA> wasn't clear to me.
> Backwards compatibility is important to me. Not all of it is finished,
> but it is important.
Oh, I definitely agree and greatly appreciate it. It's just that so much
about files changed that a note in the admin overview (if it isn't in
there already) that newinfo has remained the same would be appreciated.
> RA> The welcome message is sent as a multipart MIME message.
> It is configured to do that by default; think of internationalization.
I have no problem with it as a default, the more I think about it.
Although I do have a problem with the way (I presume) MIME tools generates
the multipart, as it's not taking advantage of the defaults and therefore
generates a much uglier multipart than is necessary. No content-type
header is necessary in the body headers unless the content-type is
something other than text/plain; charset=us-ascii. Content-disposition
isn't as clear, but I've had good luck with assuming inlining as a default
in most circumstances.
But that's not really your problem to fix.
> RA> And I couldn't find a way to turn that off.
> The welcome_files variable.
I looked that over, but it doesn't appear to give an option of just
concatenating the files together without using MIME. Although I suppose
that with a well-chosen delimiter and a fix to MIME tools to not include
so many redundant headers, there's no real difference between the two.
> So we use MIME. MIME is actually used a whole lot because there are
> some things that you just can't do without it (like reliably return
> someone's original message to them with explanatory text).
I'm actually more in support of that than I sounded; I've been arguing in
favor of MIME recently in various places. I was a bit confused about this
particular point, in retrospect.
> We're working on help docs (patches of course welcome) but the pager
> issue is sticky because mj_shell is setuid. I can probably work
> something out. For now, 'mj_shell help admin commands | less' does
> work.
I guess I don't quite understand why the setuid parts make this sticky.
At this point, mj_shell is running thoroughly as the lists user, correct?
The wrapper does the appropriate setuid to irrevocably become the lists
user. Or is it the problem with choosing what pager to fork, since PAGER
is tainted?
> RA> It'd be nice if mj_shell could handle heredocs, but I realize that's
> RA> probably pretty difficult.
> I'm not sure what you're asking for here. You have the -f option, but
> if you want to edit a multiline variable, use the 'configedit' command
> to open an editor. If you're passing a file containing commands (with
> -F) then here docs do work.
I think making the mental leap to configedit was what I was missing. Mea
culpa.
> RA> It wasn't particularly clear to me how to set global defaults.
> That is live Perl code, so the only way to access it is by editing the
> file. It gets placed in LIB under the directory holding your domains.
> Note that it also gets rewritten with each fresh install; eventually
> we'll have an extension mechanism. Suggestions as to how this should
> work are always welcome.
It looked from poking around that there's an override chain happening
here, with Majordomo first reading from LIB, then SITE, then
<domain>/GLOBAL. I was specifically looking to set a bunch of defaults
for list behavior (restricted who, restricted which, etc.) and I wasn't
sure where I should do that. Then I was trying to get it to use
qmail-queue.
> RA> Pretty much any command entered into mj_shell spewed *tons* of Perl
> RA> warnings, mostly in various places in IO::*.
> No errors here that I've seen; 5.005_02 on Linux (libc5 and glibc) and
> other testing machines,
I think the difference may be that I don't have Term::Readline::Perl? In
any event, sorry about not having the error messages; feel free to ignore
this bug until such a time as I can dig them up (which will require a
second attempt at all this). They were harmless in terms of functionality
changes.
> Well, for some things it only ever sends mail via SMTP. This can
> change, but I thought that it was a reasonable assumption that if you
> were running a mail server, you'd have something there that would speak
> SMTP to you.
This is a long and bitterly-fought argument, and you're certainly not
alone in the assumption. (mh, Netscape, Pine's default configuration, and
a number of other programs have made the same logical assumption.)
qmail takes the simple and somewhat obvious approach to putting an end to
the problems with relay rape: By default, it doesn't relay to arbitrary
sites for *anyone*. It only accepts mail for domains listed in rcpthosts.
For a Unix server that doesn't have POP accounts or otherwise support Mac
and PC users, it's also ideal to simply keep it that way. There's no
potential forging issues, no relay code to have to debug, and the
configuration is much simpler that way. The problem has always been
teaching other programs that assume an available SMTP listener to use some
other injection method instead.
> Well, I don't have qmail and that code was contributed, so I have never
> tested it. Someone with qmail is going to have to do some work here,
> and this time it's real coding work. I'm just not going to be able to
> write this.
Okay, I'll try to take a look at it when I get a chance, although that's
likely to be a while (and I'd be happy if someone else wanted to take it
on).
> RA> I'm not sure what state that left my lists in each time it happened.
> RA> I know the reason for that; qmail was refusing to accept the mail
> RA> because it thought it was a relay attempt. But nicer error handling
> RA> there would probably be good.
> Without error output I can't do anything at all.
[7356].Message from rra@stanford.edu.
[7356].Parsing entity toplevel
[7356]..Mj::Parser::parse_part: email, toplevel
[7356]...Mj::TextOutput::lists
[7356]....Majordomo::dispatch: lists, rra@stanford.edu, rra@stanford.edu
[7356].....Majordomo::lists
[7356].....Majordomo::lists..done, took 1.00 sec
[7356]....Majordomo::dispatch..done, took 1.00 sec
[7356]...Mj::TextOutput::lists..done, took 1.00 sec
[7356]..Mj::Parser::parse_part..done, took 1.00 sec
[7356].Parsing entity toplevel..executed 1, took 1.00 sec
[7356].Mj::MailOut::mail_message: /var/majordomo/tmp/mje.7356.final, rra@stanford.edu
[7356]..Failed to build envelope for mailing.
[7356].Mj::MailOut::mail_message..done, took 0.00 sec
The "failed to build envelope" part was always what it said. mj_shell
would bail out at that point with a long backtrace that unfortunately I
don't still have. :/
> Things in general don't expect mail sending functions to fail; we could
> sleep forever or just let actions finish but never actually send
> anything, but by the time mail is sent the actions that triggered the
> mail are generally complete. There is of course room for more work in
> this area.
Looking at it some more, I think the failure behavior makes sense; it
leaves a lot of trace information behind in /tmp and fails. What I didn't
know is if it left the list in an inconsistent state, but from what you're
saying I assume it didn't.
--
Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
Follow-Ups:
References:
|
|
