MESSAGE
| DATE | 2015-03-10 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] cable crimping
|
Fuck this, how about some editing? Can you edit?
If this is so burning and import, by all means, write it up as an
Article and we'll publish it in the Journal and have it reviewed.
Your welcome to keep talking, but I have things I need to get done and
one is crimping a cable and another is getting this Journal out...
Ruben
On Tue, Mar 10, 2015 at 12:36:04AM -0400, Chris Knadle wrote:
>
> On 03/09/2015 05:05 AM, Rick Moen wrote:
> >
> > Quoting Chris Knadle (Chris.Knadle-at-coredump.us):
> >
> >>
> >> On 03/08/2015 01:45 PM, Rick Moen wrote:
> >>>
> >>> Quoting Ruben Safir (mrbrklyn-at-panix.com):
> >>>
> >>>> Robert, do you have the artcile for me, PLEASE
> >>>
> >>> I hope he does _not_ have the 'cheap $5 crimper' for you. Life is too
> >>> short to spend it using crummy tools, like poorly made crimpers (and
> >>> proprietary mailing list managers with designed-in security holes that
> >>> have been unmaintained for a decade and a half).
> >>
> >> If you've managed to set up Mailman such that you're not passing it
> >> the mail via a pipe in /etc/aliases, then from what I'm hearing
> >> you're probably the only one that's gotten that to work.
> >
> > Here's the way to make the Exim4 MTA directly read GNU Mailman
> > conffiles, rather than needing special entries with pipes in
> > /etc/aliases:
> >
> > http://anonscm.debian.org/viewvc/pkg-mailman/trunk/debian/README.Exim4.Debian?view=markup
>
> If you look at the mailman_transport, that's a pipe transport.
> In the mailman_router there's a lookup done on the local_part of the
> email address for local_domains and passing the mail to Mailman via the
> mailman_transport if there's a match. That's essentially duplicating
> what /etc/aliases does, and still passes the mail via a pipe, but
> running the command via MAILMAN_USER and MAILMAN_GROUP.
>
> [...]
> > Here's what /usr/share/doc/exim4/README.Debian.html has to say about
> > that, FWIW:
> >
> >
> > 2.9. Using more complex deliveries from alias files
> >
> > Delivery to arbitrary files, directory or to pipes in the
> > /etc/aliases file is disabled by default in the Debian Exim 4
> > packages. The delivery process including the program being piped to
> > would run as the exim admin-user Debian-exim, which might
> > open up security holes.
>
> This is the case by default, but not if you set the user and group in
> the transport (such as they did in the Mailman example). Furthermore
> if you look in section 29 concerning the pipe transport, there's an
> allow_commands option to limit what commands a transport can call.
>
>
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_pipe_transport.html
>
>
> --------------------------------------------------------------------
> allow_commands Use: pipe Type: string list??? Default: unset
>
> The string is expanded, and is then interpreted as a colon-separated
> list of permitted commands. If restrict_to_path is not set, the only
> commands permitted are those in the allow_commands list. They need not
> be absolute paths; the path option is still used for relative paths. If
> restrict_to_path is set with allow_commands, the command must either be
> in the allow_commands list, or a name without any slashes that is found
> on the path. In other words, if neither allow_commands nor
> restrict_to_path is set, there is no restriction on the command, but
> otherwise only commands that are permitted by one or the other are allowed.
> --------------------------------------------------------------------
>
>
> At least with Exim using a pipe via /etc/aliases doesn't /have/ to be
> something terribly insecure. You do need to know what you're doing...
> sure.
>
> It looks like in one case I'm not actually using the command listed
> in /etc/aliases and instead re-specifying the command in the transport,
> but other cases where I am I'm using allow_commands to limit what can
> be run (and specifying the current directory, user, group, etc).
>
> But a piped command in /etc/aliases with no limiting on the command
> or the user running it, etc -- yeah that I'd be concerned about.
>
> -- Chris
>
> --
> Chris Knadle
> Chris.Knadle-at-coredump.us
|
|
