Re: [vchkpw] vlimits patch [1/??]
On Thursday 27 March 2003 14:35, you wrote: Could someone provide details of what vlimits patch does. I have seen some interesting threads about it thanks Matt. basically it lets you limit the usage of a vpopmail controlled domain. this means: limit the max no of pop accounts/forwards/aliases/mailinglists set max domain quota and max message limit (per domain) set default quota/message limit for every new user limit the permissions you have with qmail-admin so far for theory. at the moment the max number of pop accounts isn't enforced in vpopmail (actually vpopmail really doesn't care).. and most other features also only work with qmailadmin. i'm going to provide patches for the other tools, so that you won't be able to create a vpopmail pop account when max_popaccounts=10 and there already are 10 popmail accounts.. this will be more difficult for the forwards/mailingslists, as they just aliases. (and there is a limit for aliases as well). same for autoresponders. to limit autoresponders/mailinglists one would have to define a autoresponder at compile time (one thing that i think we should do) -- Mit internetten Grüßen / Best Regards --- Justin Heesemannionium Technologies [EMAIL PROTECTED]www.ionium.org
Re: [vchkpw] vlimits patch [1/??]
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 .qmailadmin-limits/mysql:vpopmail.limits 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 Heesemannionium Technologies [EMAIL PROTECTED]www.ionium.org
Re: [vchkpw] vlimits patch [1/??]
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) There were discussions on this and we determined it would be best to keep them separated out for those that read directly from the table (and I happen to have java EJB's map the attributes to these columns). Another purpose of separating them out was to allow search conditions on the elements, which is difficult with masks. Since the new field would be just a default value for the GID field of the password entry, I don't see any problem for this field being an int. something like enforced_domain_permissions and default_user_permissions .. but if it's to late to change that now, i won't object :) I don't think it should change. I actually use it with the individual fields and find it useful. i'm adding two functions now: vget_limits_default_mask (const char *domain, int *mask) vget_limits_enforced_mask (const char *domain, int *mask) Don't think you need to do this. The limits are stored in a structure. You would only need to add a single value (the mask) to the structure, then add the code to parse it out of the .qmailadmin-limits file (and write it), and add the field to the mysql table definition and queries. The API would remain the same (just a get/set of the structure). 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. Please don't. i'll also add an update script which makes the necessary changes to existing .qmailadmin-limits/mysql:vpopmail.limits 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) Its not hard to add a single field, however I went and added several (pretty much everything that people suggested months ago) but haven't integrated all of it into qmailadmin or the other programs. I have some in an older version of qmailadmin that I'm still using (haven't submitted a patch yet). -- Mit internetten Grüßen / Best Regards --- Justin Heesemannionium Technologies [EMAIL PROTECTED]www.ionium.org Thanks. Brian
[vchkpw] vlimits patch [1/??]
this enforces the disable_* vlimits:
e.g: if vlimits.disable_imap=1 it is the same as if every user has the NO_IMAP
gid flag set.
i'm going to post (a very similar one) tomorrow for .qmail-limits files.
is there vlimit support being added for postgres/sybase/oracle ?
--- vpopmail-orig-5.3.19/vmysql.c 2003-03-05 18:09:47.0 +0100
+++ vpopmail-new-5.3.19/vmysql.c2003-03-25 16:22:13.0 +0100
@@ -327,6 +327,10 @@
uid_t myuid;
uid_t uid;
gid_t gid;
+#ifdef ENABLE_MYSQL_LIMITS
+ struct vlimits limits;
+#endif
+
vget_assign(domain,NULL,156,uid,gid);
myuid = geteuid();
@@ -406,6 +410,35 @@
return(NULL);
}
mysql_free_result(res_read);
+#ifdef ENABLE_MYSQL_LIMITS
+if (vget_limits (in_domain,limits) == 0) {
+ int mask = 0;
+ if (limits.disable_pop) {
+mask += NO_POP;
+ }
+ if (limits.disable_smtp) {
+mask += NO_SMTP;
+ }
+ if (limits.disable_imap) {
+mask += NO_IMAP;
+ }
+ if (limits.disable_passwordchanging) {
+mask += NO_PASSWD_CHNG;
+ }
+ if (limits.disable_relay) {
+mask += NO_RELAY;
+ }
+ if (limits.disable_webmail) {
+mask += NO_WEBMAIL;
+ }
+ if (limits.disable_dialup) {
+mask += NO_DIALUP;
+ }
+
+ vpw.pw_gid = vpw.pw_gid | mask;
+}
+#endif
+
return(vpw);
}
Re: [vchkpw] vlimits patch [1/??]
This is very good, however you may want to move this
out of vmysql.c and put it directly in vpopmail.c
for the add_user routine.
vlimits isn't only for mysql. It also uses the
.qmailadmin-limits file for non-mysql implementations.
So the structure function vget_limits() is valid
with or without mysql.
Thanks,
Brian
this enforces the disable_* vlimits:
e.g: if vlimits.disable_imap=1 it is the same as if every user has the
NO_IMAP
gid flag set.
i'm going to post (a very similar one) tomorrow for .qmail-limits files.
is there vlimit support being added for postgres/sybase/oracle ?
--- vpopmail-orig-5.3.19/vmysql.c 2003-03-05 18:09:47.0 +0100
+++ vpopmail-new-5.3.19/vmysql.c2003-03-25 16:22:13.0 +0100
@@ -327,6 +327,10 @@
uid_t myuid;
uid_t uid;
gid_t gid;
+#ifdef ENABLE_MYSQL_LIMITS
+ struct vlimits limits;
+#endif
+
vget_assign(domain,NULL,156,uid,gid);
myuid = geteuid();
@@ -406,6 +410,35 @@
return(NULL);
}
mysql_free_result(res_read);
+#ifdef ENABLE_MYSQL_LIMITS
+if (vget_limits (in_domain,limits) == 0) {
+ int mask = 0;
+ if (limits.disable_pop) {
+mask += NO_POP;
+ }
+ if (limits.disable_smtp) {
+mask += NO_SMTP;
+ }
+ if (limits.disable_imap) {
+mask += NO_IMAP;
+ }
+ if (limits.disable_passwordchanging) {
+mask += NO_PASSWD_CHNG;
+ }
+ if (limits.disable_relay) {
+mask += NO_RELAY;
+ }
+ if (limits.disable_webmail) {
+mask += NO_WEBMAIL;
+ }
+ if (limits.disable_dialup) {
+mask += NO_DIALUP;
+ }
+
+ vpw.pw_gid = vpw.pw_gid | mask;
+}
+#endif
+
return(vpw);
}
Re: [vchkpw] vlimits patch [1/??]
On Tuesday 25 March 2003 17:34, Brian Kolaci wrote: i'm going to post (a very similar one) tomorrow for .qmail-limits files. :) i think this should stay in the vauth_getpw function (which is in vauth.c). this way, when you later decide to disable_imap=1 you won't have to change it for all the users in that domain. also authvchkpw.c (from courier-imap/authlib) directly calls vauth_getpw. and as i said.. i'm posting a patch vor vcdb.c/vpgsql.c/vsybase.c tomorrow to cover the other auth modules. anyways, i can see that the vpopmail.c:vadduser approach also has a good point: vlimits would then only serve as a default for each domain. one could still enable _single_ users to access their mail via imap/webmail/ ... or disable smtp for others. maybe some others post their opinion on this? brian: is this what vlimits was originally indented to be? a default setting for the users of a domain (well plus some generall max settings..)? -- Mit internetten Grüßen / Best Regards --- Justin Heesemannionium Technologies [EMAIL PROTECTED]www.ionium.org
Re: [vchkpw] vlimits patch [1/??]
Ahh, I think we had different thoughts on that. When I originally sent out the request for comments for the vlimits, I thought the disable_ routines were to be the defaults for new users. This was the original intent from the responses I got. This way you would be able to shut off certain services for users and you can make an exception for one or two users by using vmoduser and only enabling some of the permissions for some of the users. i.e. allow postmaster IMAP access, but no other users in the domain. I guess it could work both ways, however there's no easy way to set a default for new users (which is what the original intent was). Anyone have any comments on this? 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. What do you think? Brian On Tuesday 25 March 2003 17:34, Brian Kolaci wrote: i'm going to post (a very similar one) tomorrow for .qmail-limits files. :) i think this should stay in the vauth_getpw function (which is in vauth.c). this way, when you later decide to disable_imap=1 you won't have to change it for all the users in that domain. also authvchkpw.c (from courier-imap/authlib) directly calls vauth_getpw. and as i said.. i'm posting a patch vor vcdb.c/vpgsql.c/vsybase.c tomorrow to cover the other auth modules. anyways, i can see that the vpopmail.c:vadduser approach also has a good point: vlimits would then only serve as a default for each domain. one could still enable _single_ users to access their mail via imap/webmail/ ... or disable smtp for others. maybe some others post their opinion on this? brian: is this what vlimits was originally indented to be? a default setting for the users of a domain (well plus some generall max settings..)? -- Mit internetten Grüßen / Best Regards --- Justin Heesemannionium Technologies [EMAIL PROTECTED]www.ionium.org
Re: [vchkpw] vlimits patch
On Thursday, January 23, 2003, at 10:52 AM, Brian Kolaci wrote: Hi Ken/Bill, It appears that the last patch I sent through didn't get applied. This one contains the several extra fields as requested. Your patch applied clean to 5.3.14, but compilation failed with these errors: gcc -I. -Icdb -g -O2 -Wall -c vlimits.c vlimits.c:25: conflicting types for `vget_limits' vlimits.h:53: previous declaration of `vget_limits' vlimits.c:194: conflicting types for `vset_limits' vlimits.h:54: previous declaration of `vset_limits' vlimits.c: In function `vset_limits': vlimits.c:215: structure has no member named `disablepop' vlimits.c:217: structure has no member named `disableimap' vlimits.c:219: structure has no member named `disabledialup' vlimits.c:221: structure has no member named `disablepasswordchanging' vlimits.c:223: structure has no member named `disablewebmail' vlimits.c:225: structure has no member named `disablerelay' vlimits.c:227: structure has no member named `disablesmtp' vlimits.c:233: warning: long int format, int arg (arg 3) vlimits.c: At top level: vlimits.c:246: conflicting types for `vdel_limits' vlimits.h:55: previous declaration of `vdel_limits' make[2]: *** [vlimits.o] Error 1 make[2]: Leaving directory `/var/src/vpopmail-5.3.15' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/src/vpopmail-5.3.15' make: *** [all-recursive-am] Error 2 I'm currently working on qmailadmin to use the API. Shall I also update vdelivermail to enforce the per-domain quotas? This is not a feature I'm terribly interested in, since vpopmail already supports domain quotas through system quotas. But if you want to submit a patch, go for it. Regards, Bill Shupp
[vchkpw] vlimits patch
Hi Ken/Bill,
It appears that the last patch I sent through didn't
get applied. This one contains the several extra
fields as requested. I'm currently working on
qmailadmin to use the API. Shall I also update
vdelivermail to enforce the per-domain quotas?
My copy does this with real disk usage rather than
maildir quotas, so I'm not sure how to do this
with the maildir quotas on a per-domain basis.
Thanks,
Brian
diff -c vpopmail-5.3.14/vlimits.c vpopmail-5.3.14.old/vlimits.c
*** vpopmail-5.3.14/vlimits.c Sat Dec 7 20:19:03 2002
--- vpopmail-5.3.14.old/vlimits.c Thu Jan 23 11:38:43 2003
***
*** 38,52
limits-maxforwards = -1;
limits-maxautoresponders = -1;
limits-maxmailinglists = -1;
- limits-diskquota = 0;
- limits-defaultquota = 0;
- limits-disable_pop = 0;
- limits-disable_imap = 0;
- limits-disable_dialup = 0;
- limits-disable_passwordchanging = 0;
- limits-disable_relay = 0;
- limits-disable_smtp = 0;
- limits-disable_webmail = 0;
/* get filename */
vget_assign(domain, dir, sizeof(dir), uid, gid);
--- 38,43
***
*** 54,139
/* open file */
if ((fs = fopen(dir, r)) != NULL) {
! while (fgets(buf, sizeof(buf), fs) != NULL) {
! if ((s1 = strtok(buf, TOKENS)) == NULL)
! continue;
! if (!strcmp(s1, maxpopaccounts)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxpopaccounts = atoi(s2);
! }
! if (!strcmp(s1, maxaliases)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxaliases = atoi(s2);
! }
! if (!strcmp(s1, maxforwards)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxforwards = atoi(s2);
! }
! if (!strcmp(s1, maxautoresponders)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxautoresponders = atoi(s2);
! }
! if (!strcmp(s1, maxmailinglists)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxmailinglists = atoi(s2);
! }
! if (!strcmp(s1, quota)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-diskquota = atoi(s2);
! }
! if (!strcmp(s1, default_quota)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-defaultquota = format_maildirquota(s2);
! }
! if (!strcmp(s1, disable_pop)) {
! limits-disable_pop = 1;
! }
! if (!strcmp(s1, disable_imap)) {
! limits-disable_imap = 1;
! }
! if (!strcmp(s1, disable_dialup)) {
! limits-disable_dialup = 1;
! }
! if (!strcmp(s1, disable_password_changing)) {
! limits-disable_passwordchanging = 1;
! }
! if (!strcmp(s1, disable_external_relay)) {
! limits-disable_relay = 1;
! }
! if (!strcmp(s1, disable_smtp)) {
! limits-disable_smtp = 1;
! }
! if (!strcmp(s1, disable_webmail)) {
! limits-disable_webmail = 1;
! }
! }
! fclose(fs);
! chown(dir,uid,gid);
! chmod(dir, S_IRUSR|S_IWUSR);
} else {
! fprintf(stderr, vlimits: failed to open limits file (%d): %s\n, errno, dir);
! return -1;
}
return 0;
--- 45,190
/* open file */
if ((fs = fopen(dir, r)) != NULL) {
! while (fgets(buf, sizeof(buf), fs) != NULL) {
! if ((s1 = strtok(buf, TOKENS)) == NULL)
! continue;
! if (!strcmp(s1, maxpopaccounts)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxpopaccounts = atoi(s2);
! }
! if (!strcmp(s1, maxaliases)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxaliases = atoi(s2);
! }
! if (!strcmp(s1, maxforwards)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxforwards = atoi(s2);
! }
! if (!strcmp(s1, maxautoresponders)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxautoresponders = atoi(s2);
! }
! if (!strcmp(s1, maxmailinglists)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-maxmailinglists = atoi(s2);
! }
! if (!strcmp(s1, quota)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
! continue;
! limits-diskquota = atoi(s2);
! }
! if (!strcmp(s1, maxmsgcount)) {
! if ((s2 = strtok(buf, TOKENS)) == NULL)
!
