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]