Re: bogoutil and realpath

David Relson <[email protected]> writes:

> Accessibility of the wordlist has been verified by bogoutil before
> dbe_init is called.  Part of the success of this check should be to set
> bogohome (unless it's already set).

OK.

For some reason, the bfd->dirname component (whatever it's called, I
haven't checked, heading for bed now) is NULL, and this makes glibc
print "(null)" and other libc implementations crash (null dereference ->
SIGSEGV), and this NULL causes trouble later on.

The problem is that there's no path to extract, some function is setting
it to zero, however just assuming CURDIR_S ("." on Unix) breaks some
tests and also bogofilter and causes mail to queue up, so isn't
right. Perhaps it should try BOGOFILTER_HOME first before assuming
CURDIR_S.

> Then, in dbe_init there are calls to realpath (which can generate error
> messages) and there's also a strcmp() when can generate a different
> message.  Either of the messages is followed by an error exit.  It
> seems like some refactoring is possible.

OK.

> For example, suppose checkpath() did all the checking and message
> printing and returned true/false.  Then dbe_inint() could call checkpath
> () and error exit if appropriate.

Yup.

> This division of labor would put all the checking logic in one place
> and make clear that the top level function is responsible for exit/no-
> exit.
>
> By the way, have you read the manpage of realpath?  It says "do not
> use" :0

The GNU libc manual pages in their usual vituperating politcal agenda. I
don't care, realpath() isn't going away anywhen soon, it's in POSIX 2004
and is not marked "legacy".

David Relson <[email protected]> writes:

> More thought has made it apparent that there are additional factors
> affecting the need (or lack thereof) for path checking.
>
> The check for matching paths is needed to ensure that multiple
> databases use the same database environment.  So it only applies when
> transactions are enabled and doesn't apply to bogoutil (which only uses
> a single database).

Fine. I don't feel like diving into the code now, perhaps I'll have time
on Sunday.

-- 
Matthias Andree
_______________________________________________
Bogofilter-dev mailing list
[email protected]
http://www.bogofilter.org/mailman/listinfo/bogofilter-dev