On Wed, 30 Jul 2003, Mark Overmeer wrote:
> * Yuval Kojman (lists@xxxxxxxxxxxx) [030728 01:50]:
> > setuid enforces taintmode, not that i wasn't using it anyway. Maildir
> > routines are not taintsafe - when globbing file names they are tainted,
> > and thus cannot be used for a rename call.
>
> All boxes read directories unsafe. Probably the simplest way to solve
> this is by moving over to IO::Dir, where the IO::Handle::untaint(*DIR)
> can be used. However... maybe we need to be careful and really
> follow taint and check nicely...
>
> > I hacked it up by adding a map { /(.*)/g } when the file list from the
> > folder 'new' is read.
>
> Is is not better than a global untaint()...
mind you, i know how bad it is. by hacked i don't mean h4x0r3d, i mean
hacked like with a hatchet. i was just glueing what needed to be done
right now for it to work. I'm not happy, and as a pseudo-purist i don't
consider it too secure either - malformed data /should/ be treated with
care.
the problem is that it was not fixable from outside the modules, and
that's why i brought it up.
What i think would be nice is an inheritable untaint attribute to
Mail::Box objects, which would force reduntant data checking and
extraction via regexes or untainting via XS, thus allowing safe
treatment of data, and transperrant use in taintsafe environments.
an example - since the path came from the maildir and is going back
there it can be safe to assume, after minimal sanity checks that you can
safely assume a filename read from the fs is safe to rename ro, post
munging. The sanity checks, like interpolating the path, making sure
it's an atomical basename, and that we provide the actual path to it
ourselves are probably not needed for an MUA, since if we don't trust
the filesystem, who can we trust, eh?
Mail::Box::Manager->new(taintsafe => 1);
is my dream way of forgetting the problem.
This is wishful thinking though, i know. I'd be happy to help out, and
i've got a few other wises i'm going to try and write a la Mail::Box,
for Mail::Box soon enough (uidl is driving me crazy, i don't know what
i'll do for uids and uvers in IMAP), etc etc.
> > chroot problem inelegantly resolved by preloading modules. this also
^^^^^^^^^^^
> There are many more modules you want to preload; User::Identity stuff,
> Date::Parse, URI, Mail::SpamAssassin etc etc... everything which can
> get 'require'd later on... this is more complex than it looks, but I am
> willing to consider it. Downside: in mod_perl each process will be huge
> while far from everything is being used. Any ideas how to solve this
> without too many manual interference?
my thoughts were quite blunt - represent Mail::Box dependancies in a
tree, and then implement a way of autoloading paths semiminimally, but
completely.
The idea is - wasting a lot once is less than wasting a little many
times.
This is mainly for the copy-on-write benefits of forking, and chrooting
to work - Though you can place the source in the jail it's not pretty -
even with linux rebinding of branches.
didn't do much mod_perl, i'm afraid. can't get any books round here, and
i'm not finding good online resources. peh.
Forgive my beat up language, i've been up for too long, and am on the
verge of collapse... =P
--
Yuval Kogman ( nothingmuch@xxxxxxxxxxxx | nothingmuch@xxxxxxxxxx )
kung foo master: /me has realultimatepower.net: neeyah!!!!!!!!!!!!!
et perl hacker. !@# http://nothingmuch.woobling.org/ gpg:0xEBD27418
http://wecanstopspam.org/ http://www.habeas.com/
|
