Hi Paul,
Thanks for making this a lot more clear to me. To make the wiki-entry
complete, (I'll put it in later) how is the score() pseudo function
working?
I'm assuming ANY is always lower than a specific login,
0.0.0.0 is lower than a specific ip,
port 0 is lower than a specific port.
In that order.
Or written differently:
specific port: +1 points
specific host: +2 points
specific login: +4 points
Am I right?
What happens if the userid is empty? Is the login used, or is login
denied? (I guess the latter, but your example suggests differently)
If you ever feel like breaking backward compatibility, using regular
expressions for login would be a very useful feature.
SELECT sock_allow, sock_deny FROM usermap WHERE 'username' REGEXP login
is possible in MySQL. In normal situations only field REGEXP '/regexp/'
is used, but matching a value to a regular expression in the database is
also possible. (dunno 'bout postgresql and sqlite, or anything about
performance)
Grtz, Casper
> > I really like to know exactly how the deny/allow rules are followed, is
> > it a single record that is evaluated, are record processed in order? and
> > if they are, in what order?
>
> In pseudocode the algorithm is as follows
>
> Given a user who tries to login with 'username' on 'clientsocket':
>
> rows = select sock_allow,sock_deny,userid
> from usermap
> where login in ('username','ANY')
> foreach row in rows:
> if match(clientsocket,sock_deny):
> deny_access
> rowscore = score(clientsocket,sock_allow)
> if rowscore > bestscore:
> bestscore = rowscore; bestrow = row
>
> if bestrow:
> if bestrow['login'] == 'ANY':
> real_login=expand(username, bestrow['userid'])
> else:
> real_login=bestrow['userid']
>
>
> From this you can deduce that setting up the policy you want, you
> shouldn't use sock_deny, but rather map ANY user to a non-existent userid.
>
> login sock_allow sock_deny userid
> ---------------------------------------------------------------
> ANY inet:0.0.0.0:0 nosuchusergoawaynow
> ANY inet:0.0.0.0:110
> username inet:0.0.0.0:143
>
> this way, users will be mapped to a non-existant user by default,
> denying them access. The second and third records are more specific so
> when anyone tries to login on port 110, access is granted. But only
> 'username' is allowed to use port 143.
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
