On 2020/01/16 13:58, Klemens Nanni wrote:
> On Thu, Jan 16, 2020 at 01:16:27PM +0100, Alexandr Nedvedicky wrote:
> > sentence 'The syntax is similar to the one for ports' sets my
> > expectations
> > I can define a range of users in the same way I define a range of ports.
> > Looks useful to me, though a bug in parse.y might be just a tip of
> > iceberg
> > here.
> I *assume* Vadim tripped over this implication, but that's what I wanted
> to know. That said, probably being biased here, "similar to the one for
> ports" does not read like "the same as ports" to me.
>
> After convincing Sasha in the hackroom that the range syntax for
> user/group is rather misleading and not worth the effort, he in turn
> made a convincing point about how mapping user ranges with existing
> syntax might go wrong:
>
> $ echo 'pass on lo proto tcp user { >= 1000 , <= 2000 }' | pfctl -vnf-
> pass on lo proto tcp all user >= 1000 flags S/SA
> pass on lo proto tcp all user <= 2000 flags S/SA
>
> Note how --depending on other keywords-- the provided inclusive range
> might evaluate to rules that pass more than desired; above example will
> pass all users since the [1000, 2000] is eventually used as [1000, inf]
> and [0, 2000] which together make for [0, inf], that is all users.
>
> With proper ranges as for ports the ruleset would evaluate to what users
> actually wanted. So ranges *can* already be covered but not in a sane
> and actually safe way.
>
This is a valid use for ranges and we already have the >< operator.
As it excludes boundaries it's a bit awkward to use (in the same way
that >< is awkward with ports) but it does do the job.
I think the widespread use of user:group syntax in other parts of the
OS and in applications makes it much too dangerous to allow using e.g.
1:1000 as a range operator for this in pf. People who are reasonably
familiar with the syntax won't refer to the docs unless something
doesn't work.
Allowing something like "1 : 1000" would be pretty safe but I think
a bit confusing.
