increasing NGROUPS_MAX

Hi,

In order to increase the number of supplemental groups a user can be in,
one needs to bump NGROUPS_MAX in the sources.  This will require a
rebuild of the kernel but also of the userland tools that use
NGROUPS_MAX.

This could be made less intrusive if the userland tools would use
sysconf(_SC_NGROUPS_MAX) instead.  Of course this means that all those
tools that currently use static arrays initialized to NGROUPS_MAX + 1
need to be redone dynamically...

-Jan

--

-- 
"Drink up. The world's about to end."
"This must be Thursday. I never could get the hang of Thursdays."

Re: increasing NGROUPS_MAX

On Aug 2, 2005, at 10:33 AM, Jan Schaumann wrote:

> This could be made less intrusive if the userland tools would use
> sysconf(_SC_NGROUPS_MAX) instead.  Of course this means that all those
> tools that currently use static arrays initialized to NGROUPS_MAX + 1
> need to be redone dynamically...

I would encourage everyone to look at how this was addressed in Mac  
OS X 10.4.  Their solution also provides for nested group  
functionality, as well as providing a more useful interface to groups  
(i.e. "is this user a member of this group" as opposed to "get list  
and traverse it myself to find out if a user is a member of a group").

Start with the memberd(8) man page.

-- thorpej

optional PAM modules?

Experimenting with LDAP and in particular the pam_ldap
module I found it extremely annoying that the openpam
framework locked me out completely if just a single
module listed in the pam.d/x file was missing.
The LDAP stuff is in pkgsrc, and it just happens during
tests and updates that a pkg is not present at some time.

Would it be possible to just ignore lines in the pam
configuration file on system errors if they are optional,
i.e. "sufficient"?
I've used the appended patch to save miself, but given
the complexity of PAM configuration I can't tell whether
this had unexpected security implications.

Could someone more familiar with the matter have a look
at this?

best regards
Matthias

Index: openpam_configure.c
===================================================================
RCS file: /cvsroot/src/dist/openpam/lib/openpam_configure.c,v
retrieving revision 1.4
diff -u -r1.4 openpam_configure.c
--- openpam_configure.c	16 Mar 2005 15:28:55 -0000	1.4
+++ openpam_configure.c	2 Aug 2005 17:49:40 -0000

Re: optional PAM modules?

On Tue, 02 Aug 2005 21:03:11 +0200
Matthias Drochner <M.Drochner <at> fz-juelich.de> wrote:

> Experimenting with LDAP and in particular the pam_ldap
> module I found it extremely annoying that the openpam
> framework locked me out completely if just a single
> module listed in the pam.d/x file was missing.
> The LDAP stuff is in pkgsrc, and it just happens during
> tests and updates that a pkg is not present at some time.
> 
> Would it be possible to just ignore lines in the pam
> configuration file on system errors if they are optional,
> i.e. "sufficient"?
> I've used the appended patch to save miself, but given
> the complexity of PAM configuration I can't tell whether
> this had unexpected security implications.

I don't have much idea about PAM, but your patch might
fix the login problem I've found when the release is built
with USE_KERBEROS=no, because the pam_ksu is missing
and it refuses to login.

Thanks.

Re: increasing NGROUPS_MAX

On Tue, Aug 02, 2005 at 01:33:07PM -0400, Jan Schaumann wrote:
> Hi,
>
> In order to increase the number of supplemental groups a user can be in,
> one needs to bump NGROUPS_MAX in the sources.  This will require a
> rebuild of the kernel but also of the userland tools that use
> NGROUPS_MAX.
>
> This could be made less intrusive if the userland tools would use
> sysconf(_SC_NGROUPS_MAX) instead.  Of course this means that all those
> tools that currently use static arrays initialized to NGROUPS_MAX + 1
> need to be redone dynamically...
>

Be aware that just changing NGROUPS_MAX could cause all sorts of
problems since this value is also used for NGROUPS.  And NGROUPS
is used by things like RPC credentials (i.e. NFS) which doesn't
provide for any more than 16 simultaneous groups...

Any userland tools and library routines that initialize static arrays
to NGROUPS will also need to be redone dynamically.

Brian

Re: Bittorrent package and 'broken libc' claim

Joerg Sonnenberger writes:

> >    The optional bufsize argument specifies the file's desired buffer
> >    size: 0 means unbuffered, 1 means line buffered, any other positive
> >    value means use a buffer of (approximately) that size. A negative
> >    bufsize means to use the system default, which is usually line
> >    buffered for tty devices and fully buffered for other files. If
> >    omitted, the system default is used.
> 
> Ah! I've seen this problem on DragonFly too. Now it makes perfect sense.
> Turning off buffering means a few things in the BSD libc:
> (a) Reads are done with a buffer size of 1. That might arguable be a bug
> for fread() or not, it's hard to say. I'm investigating.
> (b) All open FILEs are fflushed before reading from such a file.
> (c) Certain IO routines are checking for '\n' and handling it specially.

I'd guess that the reason for (a) is to support (c)?

But if that's the case, it probably is an inefficiency to break
block-fread()'s down into single-byte reads.

Perhaps it would be better to train fread() to read directly into the
passed buffer, rather than repeatedly call __srefill() and copy the
buffer - which in the unbuffered case is a 1-byte buffer.

Though one has to wonder what the justification for using stdio for
purely unbuffered access is...  Maybe it's a Python programmer thing
:)

Re: Bittorrent package and 'broken libc' claim

On Sat, Aug 06, 2005 at 02:08:58PM +1200, Dave Sainty wrote:
> Joerg Sonnenberger writes:
> 
> > >    The optional bufsize argument specifies the file's desired buffer
> > >    size: 0 means unbuffered, 1 means line buffered, any other positive
> > >    value means use a buffer of (approximately) that size. A negative
> > >    bufsize means to use the system default, which is usually line
> > >    buffered for tty devices and fully buffered for other files. If
> > >    omitted, the system default is used.
> > 
> > Ah! I've seen this problem on DragonFly too. Now it makes perfect sense.
> > Turning off buffering means a few things in the BSD libc:
> > (a) Reads are done with a buffer size of 1. That might arguable be a bug
> > for fread() or not, it's hard to say. I'm investigating.
> > (b) All open FILEs are fflushed before reading from such a file.
> > (c) Certain IO routines are checking for '\n' and handling it specially.
> 
> I'd guess that the reason for (a) is to support (c)?

That's one reason. The other is simply that doing reads of 1 byte each
are the simplest way to use the same algorithm for buffered and
not-buffered operation 

> But if that's the case, it probably is an inefficiency to break
> block-fread()'s down into single-byte reads.

Yes, I think so.

> Perhaps it would be better to train fread() to read directly into the
> passed buffer, rather than repeatedly call __srefill() and copy the

ifconfig -h patch

Hi,
The following small patch adds the '-h' option to ifconfig(8). As you may
have already gussed, it prints the byte statistics of a given interface
in human-readable format. This is something that I miss often, but
I don't know how many people would want this. Note that I'm not breaking
anything (I guess): it's a new flag and scripts that already depend on
the old -v format will work.

An example output (addresses removed):

> ifconfig -v ex0
ex0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=3f00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        enabled=3f00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        address: 00:00:00:00:00:00
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        input: 4701561 packets, 6885740641 bytes, 11206 multicasts
        output: 6499381 packets, 1615921802 bytes, 473 multicasts
        inet 0.0.0.0 netmask 0xffffffff broadcast 255.255.255.255
> ifconfig -hv ex0
ex0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=3f00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        enabled=3f00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        address: 00:00:00:00:00:00
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        input: 4701585 packets, 6.4G bytes, 11208 multicasts
        output: 6499405 packets, 1.5G bytes, 473 multicasts
        inet 0.0.0.0 netmask 0xffffffff broadcast 255.255.255.255

Re: Bittorrent package and 'broken libc' claim

On Sat, Aug 06, 2005 at 02:08:58PM +1200, Dave Sainty wrote:
> 
> Though one has to wonder what the justification for using stdio for
> purely unbuffered access is...  Maybe it's a Python programmer thing :)

Portability

	David

--

-- 
David Laight: david <at> l8s.co.uk

Re: optional PAM modules?

On Dec 23,  3:38pm, Matthias Drochner wrote:
} 
} Experimenting with LDAP and in particular the pam_ldap
} module I found it extremely annoying that the openpam
} framework locked me out completely if just a single
} module listed in the pam.d/x file was missing.
} The LDAP stuff is in pkgsrc, and it just happens during
} tests and updates that a pkg is not present at some time.
} 
} Would it be possible to just ignore lines in the pam
} configuration file on system errors if they are optional,
} i.e. "sufficient"?

     What happens if the module that goes missing is one that works
with a token used by system staff?  Or, what happens if the module
wasn't removed by system staff?  People would want to know about these
situations right away.  Besides, a module going missing is a huge
change to system security.  This isn't something that should happen
silently.  I checked the PAM specification and although it talks about
configuration details, I didn't find anything about what happens if a
module is missing.  PAM was originally created by Sun, so when in
doubt, I use Solaris as a reference.  This is what the pam.conf(5)
manpage on Solaris 9 says:

     If any entry in pam.conf is incorrect, or if a  module  does
     not  exist  or  cannot be opened, then all PAM services fail
     and users are not be permitted  access  to  the  system.  An
     error is logged through syslog(3C) at the LOG_CRIT level. To
     fix incorrect entries in pam.conf,  a  system  administrator
     can  boot  the  system  in maintenance mode (single user) to