Index: [thread] [date] [author] [stats]
  From: markus schnalke <meillo@marmaro.de>
  To  : <masqmail@marmaro.de>
  Date: Tue, 28 Feb 2012 18:45:42 +0100

Re: [masqmail] Config file parser: rval

[2012-02-22 16:58] Jan Hauke Rahm <jhr@debian.org>
> On Wed, Feb 22, 2012 at 04:28:49PM +0100, markus schnalke wrote:
>>
>> These kinds of protection are useful if you process user input, but
>> are they useful here? The code parses the configuration files, which
>> are under the admin's control, most likely that's root. If he likes to
>> break his own system, then he may just do so.
>
> I consider root a user just like any other. It may well be a typo done
> by root (or a windows-formatted file he copy&pasted into his putty
> session).

Unix puts the user in full control. The system assumes you know what
you're doing. Yes, this concept changed over the years, but still I
believe that it is an important step towards simplicity. You can't
cover all possibilities anyway and most likely you don't even know, so
better don't start at all to guess.


> If his input can break in a way that leads to corruption,
> segfault, or the like, then it's a bug in the application -- doesn't
> matter if I made the mistake as root or user.

True and therefore masqmail tries not to treat them differently.

> If a typo means the
> application won't work, that's bad luck indeed.

The application may have a hard job to separate typo from intention.
We only should care that no security problems appear. (The conf file
parser will error if the syntax is invalid.)


>> I plan to rework the conf parser more extensively. This is related to
>> my preparation to a compiler construction exam currently. ;-)
>
> libconfig? :)

Surely not! (I guess you already guessed it.)


> If you follow my separation of input parsing problems above, I'd say,
> the parser should catch case 1 while the application should, on a higher
> level, catch case 2 (be it by just terminating with an error message).

Agreed.


>> > If it actually works,
>> > maybe read_lval() and read_rval() could make use of a common new
>> > function that simply parses a string. It wouldn't even hurt if one could
>> > quote before the '=' sign anyways, would it?
>>
>> If it wouldn't hurt, what use are the quotes then anyway?
>
> Sure. My point was: the is code duplicated. If you want to parse quoted
> strings, I'd allow quoted strings for lval, too. Just to avoid the
> duplication of code.

Ah, now I see. But lvals are single words, whereas rvals can contain
whitespace. I'll have a look, although I guess that rval will need to
check for folded lines and stuff, whereas lval is simply the first
word on the line, followed by an equality sign. I haven't worked in
that code yet and especially I haven't written it. For the current
code you may be right, but that could change after I reworked it.


Probably we should stop producing too much of the ``hot air'' and get
some real work done. I mean, I should present results, then we can
discussion on them.


> Hauke
>
> ...who put waaaay much more thought into this than planned. Why again am
> I on this mailing list?

Hehe. Well, if you think you have valuable comments, then they are
always welcome.


meillo

... who should work on a more important project than masqmail, but
likes to work on masqmail much more, currently. ;-)


Index: [thread] [date] [author] [stats]