Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h?
On 23.03-12:23, Boris Kochergin wrote:
[ ... ]
yes, that's great but you may be surprised to learn that it doesn't
actually solve your problem. i think (and without looking
specifically at the impact my even be confident enough to say
definately) if you get a groups list it will only be cropped and the
error message is being erroneously avoided, not corrected. i'd also
suggest that you may be opening up your system to some overflows
although, generally, the code sections use the same limits and so
you might get away with it.
[ ... ]
On my 7.0 system, and a kernel recompiled with NGROUPS_MAX set to 64, a
getgrouplist() call for a user who is in more than 16 groups (24, to be
exact) will populate the array specified by the gid_t *groups argument
with the 24 groups the user is in, in addition to the group specified in
the gid_t basegid argument. The value of the variable specified in the
int *ngroups will also be 25, and the getgrouplist() call will return
0. So, as far as being a hack for a specific problem, it seems to work
properly.
yeah, looked at it now. NGROUPS is defined from NGROUPS_MAX (bad
memory). the other significant values would be KI_NGROUPS which is
not defined from NGROUPS_MAX; neither are the IPC or RPC relevant
values, although, as i said they use their own max values for validation
(i.e. they don't suddenly using NGROUPS_MAX instead of CMGROUPS) so
probably won't overflow trivially but i wouldn't say they are
necissarily safe.
suffice to say if it works for you great but be aware that you may
have security and other issues associated with the change.
[ ... ]
Sure, I'll test the patch. Can you point me at it?
sure, attached. but note it's functionally zero progress, it only
looks to remove the dependancy on NGROUPS_MAX as static definition
and make SC_NGROUPS_MAX a writable and referenced value. however, it
won't currently give you the extra groups you want because it defines
other values from _NGROUP_COMPAT (which is 16) until i can complete
the changes to a stable state.
it would still be nice to know that i haven't messed it up
completely and that, at the very least the system still boots and
runs with it.
p.s: i've gotta finish some bloody web stuff and then i'll throw
some more time at it this afternoon.
--
t
t
w
Index: contrib/openpam/lib/openpam_borrow_cred.c
===
RCS file:
/home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/contrib/openpam/lib/openpam_borrow_cred.c,v
retrieving revision 1.1.1.9
diff -b -u -r1.1.1.9 openpam_borrow_cred.c
--- contrib/openpam/lib/openpam_borrow_cred.c 21 Dec 2007 11:49:29 -
1.1.1.9
+++ contrib/openpam/lib/openpam_borrow_cred.c 4 Feb 2009 16:38:46 -
@@ -60,6 +60,7 @@
struct pam_saved_cred *scred;
const void *scredp;
int r;
+ int ngroups ;
ENTERI(pwd-pw_uid);
r = pam_get_data(pamh, PAM_SAVED_CRED, scredp);
@@ -73,26 +74,55 @@
(int)geteuid());
RETURNC(PAM_PERM_DENIED);
}
- scred = calloc(1, sizeof *scred);
- if (scred == NULL)
- RETURNC(PAM_BUF_ERR);
- scred-euid = geteuid();
- scred-egid = getegid();
- r = getgroups(NGROUPS_MAX, scred-groups);
- if (r 0) {
- FREE(scred);
- RETURNC(PAM_SYSTEM_ERR);
- }
- scred-ngroups = r;
+/* get the maximum number of system groups */
+#if _POSIX_VERSION 199212
+ ngroups = sysconf( _SC_NGROUPS_MAX ) ;
+#elif defined(NGROUPS_MAX)
+ ngroups = NGROUPS_MAX ;
+#else
+ ngroups = _NGROUPS_COMPAT ;
+#endif
+/* initally allocate enough memory for max_groups */
+ scred = malloc( sizeof(struct pam_saved_cred) +
+ ngroups*sizeof(gid_t) ) ;
+ if( scred == NULL )
+ RETURNC( PAM_BUF_ERR ) ;
+/* set the save values */
+ scred-euid = geteuid() ;
+ scred-egid = getegid() ;
+/* save groups into our (probably) oversized memory allocation */
+ r = getgroups( ngroups, scred-groups ) ;
+ if( r 0 ) {
+ FREE( scred ) ; /* call PAM's free macro */
+ RETURNC( PAM_SYSTEM_ERR ) ;
+ } ;
+ scred-ngroups = r ;
+ ngroups = r ngroups ? r : ngroups ; /* choose the smallest */
+ /* ... number of groups to allocate */
+ ngroups = ngroups _NGROUPS_COMPAT ? ngroups : _NGROUPS_COMPAT ;
+ /* but keep it within expected minimum value */
+ /* XXX: we don't really want this but
until we get
+* educated on the implications this is
probably safe
+* and certainaly compatible */
+/* realloc, releasing unneeded memory */
+ scred = realloc( (void*)scred,
+ sizeof(struct pam_saved_cred)+ngroups*sizeof(gid_t) ) ;
+
Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h?
On 23.03-10:20, Boris Kochergin wrote: [ ... ] Well, bumping it does get rid of messages like: Mar 22 20:44:26 hydrogen sshd[96152]: getgrouplist: groups list too small Mar 22 20:44:26 hydrogen sshd[96152]: fatal: initgroups: [user]: Invalid argument yes, that's great but you may be surprised to learn that it doesn't actually solve your problem. i think (and without looking specifically at the impact my even be confident enough to say definately) if you get a groups list it will only be cropped and the error message is being erroneously avoided, not corrected. i'd also suggest that you may be opening up your system to some overflows although, generally, the code sections use the same limits and so you might get away with it. [ ... ] I'd love to see a resolution to this other than having to recompile the kernel. Let me know if I can help things along somehow. if you can grab my patch, confirm it builds for you and that it doesn't crash your system , that would be a big help. unfortunately i was going to test it on my xen box only to discover that it doesn't work with amd64 yet. i'm currently coding blind and am not a good programmer so this is bad[tm]. if you can do this and are happy to run a few further tests after that then i'll be sure to put some heat under the rest of the process and get the group limits removed correctly. -- t t w ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: removal of NGROUPS_MAX dependancy from base
On 22.02-16:28, Brooks Davis wrote: On Sun, Feb 22, 2009 at 11:07:19AM +, ttw+...@cobbled.net wrote: On 21.02-22:49, Julian Elischer wrote: [ ... ] this patch should remove the dependancy on the definition of NGROUPS_MAX as a static constant and implement it as a writable sysconf variable of the same. it should also make the necessary changes to the codebase to support those. [ ... ] What do you do about NFS? I seem to remember that NFWS had a maximum number of groups supported.. NFS will be supported by mapping 16 groups into the auth_unix structure dynamically. my intention is to try and make this transparent by allocating moving the 'most used' groups into that mapping as user processes check them, however, this is very conceptual at the moment and needs more thought as well as validation from others with more experience. I think this behavior will probably need to be configurable by the administrator because some sites are probably using groups to supply negative permissions. It's quite reasionable to argue that's a bad idea, but we need to take some care since people do occationally use that feature. agree. i'm hoping to make the rpc group allocations dynamic and thus, mostly transparent, but would suggest the only consistent way administrators to set permissions (when NFS is required) is to restrict NGROUP_MAX to 16 or less. i intend this to be the default, changed by sysctl/sysconf. my current primary concern is with software that defines it static arrays with a length of NGROUPS_MAX and then forgets to sanitize 'ngroups' count against that maximum but no idea how to catch those except too say that is 'broken'. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [BUGI] IOCTL :Facing problems while acccessing data from kernel space
On 28.09-13:40, rashmi ns wrote:
[ ... ]
I was trying to add a new ioctl command like
#define HDLCMODE _IOR('6',0xF,int)
when i trying to uprintf the data which was sent from the user-space in
the device-driver-ioctl-routine i'll get a different value than which was
passed. Can anybody please tell me why this is happening . I pass the
address of an integer where data is stored from the user space as third arg
to the ioctl call .
i would guess that it's a simple typo and your pointer conversions
are off somewhere.
i.e.
uprintf( %d, (int*)data ) ;
instead of
uprintf( %d, *(int*)data ) ;
otherwise, use a debugger or post the code.
--
t
t
w
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [BUGI] Re: Porting from linux to freebsd help needed
On 13.09-10:16, rashmi ns wrote: [ ... ] I wanted to add a psuedo network driver can any one tell me what else needs to be done here to provide a simple psuedo interface not to repeat what david said but look at /usr/src/sys/net/if_disc.c for information. the code supplied is only enough to handle the module loading -- nothing to do with network interfaces (except that they may also be modules). most of the magic is handled by the macro definitions and kernel callbacks. if you're really stuck try posting the full source. if you are looking to implement a pseudo device you may wish to look at netgraph -- i have no experience of it but rumour suggests it is an effective way to stack protocol handlers, drivers and other network magic. -- t t w ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
