On Tuesday 25 March 2003 18:25, Brian Kolaci wrote:
> Do you think we need both domain permissions and
> default new user permissions for each type of permission?
> (This is the case for quotas, a domain limit and a default
> for new users).
> I like the idea of having both (which just generates more
> work...).  But we didn't take that into account with the
> original design.
> I would say that we should do what you were intending
> by using the current values as "domain" permissions, and
> add a field for "default_user_permissions" that would
> populate the gid field of the user password entry.
> What I would also do is encapsulate the code you
> wrote into a function (you don't need the #ifdefs)
> and have it return the mask which can be AND'd with
> the gid field of the password entry.  This masking
> function could go into vlimits.c and called in the
> vauth_getpw() functions.

sounds good to me. I guess a single field added to the mysql table for 
default_user_permissions is enough, as it only has to contain the mask. 
(Well, we could have done this to the disable_* as well, it wouldn't bloat 
the mysql table that much)
something like enforced_domain_permissions and default_user_permissions .. but 
if it's to late to change that now, i won't object :)

i'm adding two functions now:
vget_limits_default_mask (const char *domain, int *mask)
vget_limits_enforced_mask (const char *domain, int *mask)

but I thought about making some changes to vset_limits/vget_limits plus 
changing the structure of .qmail-limits/mysql:vpopmail.limits
to drop all the disable_* and replace it with the masks.

i'll also add an update script which makes the necessary changes to existing 

only someone would have to alter the qmailadmin for me (i've never touched 
that thing :) )

(well .. i will only start with the altered tables/.qmailadmin-limits files if 
you say it's ok.. I don't know how many out there are already using vlimits. 
i think the masks help adding future disable flags without having to change 
the table structure every time, so yes, we have a incompatible update this 
time, but _only_ this time)

Mit internetten Grüßen / Best Regards
Justin Heesemann                                        ionium Technologies
[EMAIL PROTECTED]                                                www.ionium.org

Reply via email to