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 =      NULL
ROAM    NAS-IP-Address =     NULL
NEWS    NAS-IP-Address =  NULL
COVAD  NAS-IP-Address =      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='' \
        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,


On Fri, 2 Apr 2004, Peter Palmreuther wrote:

> OK, an example: PW_GID is set to 44 (0x2C), that's 0x04 + 0x08 + 0x20,
> 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
> & 01000000
> ==========
>   00000000 = 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
> & 01000000
> ==========
>   01000000 = 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 :-)
> --
> Best regards
> Peter Palmreuther
> Once a job is fouled up, anything done to improve it only makes it
> worse.

Reply via email to