Sorry for the top post...
Peter, thanks for that info. Between you and a co-worker, I've got this
figured out. It's a very cool way to set user rights; I like it.
So in case anyone is wondering, here's the magic to make gnu-radius obey
these flags. I'll use our setup as an example here.
We want to look at dialup perms using the standard vpopmail dial/no-dial
gid flags. We are using V_USER0 for roaming dial, V_USER1 for news access
(Giganews authenticates users via radius), and V_USER2 for Covad PPPoE.
In gnu-radius, there are three files to work with to have it send a
different SQL query based on where the radius auth request comes from.
First, define what's what in the "huntgroups" file:
# this config will tag each NAS client with a name that is recognized
# in the users file. In the users file, an additional sql conditional
# is added to discriminate between local, roaming and news access
LOCAL NAS-IP-Address = 192.168.0.2 NULL
ROAMNAS-IP-Address = 10.0.0.9 NULL
NEWSNAS-IP-Address = 10.1.1.5 NULL
COVAD NAS-IP-Address = 10.2.2.3 NULL
Then the "users" file. Note the decimal representations of each gid
flag in the "Auth-Data" field:
# also see "huntgroups"... Here we are using tags from huntgroups to
# assign extra "Auth-Data" to a request based on which nas the request
# comes from.
DEFAULT Huntgroup-Name = LOCAL,
Auth-Type = SQL,
Auth-Data = "64"
Service-Type = Framed-User
DEFAULT Huntgroup-Name = ROAM,
Auth-Type = SQL,
Auth-Data = "128"
Service-Type = Framed-User
DEFAULT Huntgroup-Name = NEWS,
Auth-Type = SQL,
Auth-Data = "256"
Service-Type = Framed-User
DEFAULT Huntgroup-Name = COVAD,
Auth-Type = SQL,
Auth-Data = "512"
Service-Type = Framed-User
Lastly, we write a appropriate SQL query in the "sqlserver" file to
generate a request with an "AND" clause that checks the gid mask based on
which NAS the request came in on:
auth_query SELECT pw_passwd \
FROM vpopmail \
WHERE pw_name='%u' \
AND pw_domain='blah.net' \
AND !(pw_gid & %C{Auth-Data})
So a request from say, our local dial pool would generate a SQL query that
looks like this:
select pw_passwd from vpopmail where pw_name='chuck' and !(pw_gid & 64);
If that came in from Giganews, it would look like this:
select pw_passwd from vpopmail where pw_name='chuck' and !(pw_gid & 256);
Again, not totally relevant to vpopmail, but it's in the archives, so
maybe someone looking to auth other services out of vpopmail will find
this one day.
Thanks all,
Charles
On Fri, 2 Apr 2004, Peter Palmreuther wrote:
> OK, an example: PW_GID is set to 44 (0x2C), that's 0x04 + 0x08 + 0x20,
> means NO_WEBMAIL, NO_IMAP & NO_RELAY.
>
> To figure if the user is set to NO_DIALUP check:
>
> PW_GID & 64 (0x40 for NO_DIALUP):
>
> 44 & 64 = 0
> 0x2C & 0x40 = 0
>
> Or in binary notation:
> 00101100
> & 0100
> ==
> = 0x00 == 0 decimal.
>
> So this user has not NO_DIALUP set.
>
> No imagine a user set to NO_DIALUP, NO_WEBMAIL and NO_RELAY:
>
> 0x04 + 0x20 + 0x40 = 0x64
>4 + 32 + 64 = 100 (decimal)
>
> PW_GID & 64 (0x40 for NO_DIALUP):
>
> 100 & 64 = 64 (decimal)
> 0x64 & 0x40 = 0x40
>
> 01100100
> & 0100
> ==
> 0100 = 0x40 == 64 decimal.
>
> So to see if a flag is set AND operate on PW_GID and FLAG and see if
> the result is different from zero. As every flag gets a different bit
> assigned this bit, and only this bit, will be set when you AND operate
> and this bit was set in PW_GID's value.
>
> In cat it is really quite easy to handle and most programming
> languages should be able to bit-operate with integer values too. So
> you wouldn't even have to convert PW_GID into a "real bitmask", in
> fact the integer already is one: just use an arbitrary calculator to
> translate an arbitrary decimal value into binary representation.
> No "translate" all the hex values for different flags into binary and
> you'll see: they all have /exactly/ one bit set to 1. Not more, not
> less. And this is all about how it works :-)
>
> HTH
> --
> Best regards
> Peter Palmreuther
>
> Once a job is fouled up, anything done to improve it only makes it
> worse.
>
>
