marty at goodoldmarty.com
Sun Sep 14 09:19:00 PDT 2008
> The group limit in uClibc is limited by the total number of names and
> how long each name is.
> The expected username/groupname max is 16 characters, and uClibc has a
> default buffer size of 256.
> Therefore the max number of users with the max number of characters
> is: 16 (256 / 16).
> This is fine for a single user or simple embedded system, but for
> everything else (like embedded ssh servers with tons of users), this
> can be pathetic.
> I have a patch for uClibc 0.8.28.3 and uClibc 0.8.29, where I set the
> passwd and group to be much more: 8192.
> WIth the default username/groupname max (16), that is only 512 names.
> Which is still small, if this is to be a system with tons of users.
> Not to mention the number of people who need and use names longer than
> 16 characters in length.
> Scale this value depending on how high you need it to be.
> Alternatively, a patch for uClibc group needs to be made for using
> dynamic arrays or just reading the files (/etc/passwd, /etc/group)
> without buffering it in some array (aka, processing the data inline).
> uClibc 0.8.29 moved the buffer size limit to a 'make config' option,
> but they put a limit in their config option to be 1024 max.
> This was changed by my attached patch to 8192 and if you still need
> more, look at the patch and make the changes yourself.
> Note: the pwd buffer size should not need as much as the grp buffer
> size because the buffer size seems to only represent all the data
> until a newline is found. The pwd file only contains one username and
> one group name (and other important stuff). I extended this length to
> account for usernames, group names, home directory names, shell names,
> and comments.
> I particularly needed this because I use group names and permissions
> to lock down my system as much as possible to protect it from its own
> users, resulting in really long group lines.
> How are patches to be submitted and handled here when they are to be
> discussed or proposed?
> Is this current method I am using fine?
Everyone knows uClibc targets embedded microcontrollers like ARM7 or 9.
uClibc is not HLFS. What list should you be posting to really?
Glibc is far more practical for servers and desktops using normal i386 types.
On i386 uClibc is designed to be insufficient and will never interface properly
with the applications you mentioned due to the built-in limitations.
All your problems will go away if you use glibc. I use glibc on my CF based
embedded systems. Still very small; just leave out the stuff you don't need.
I can run servers off a < $10(USD) CF card with room to spare.
If you play the Windows CD backwards, you may hear satanic messages.
But more frightening; when you play it forward, it installs Windows!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: OpenPGP digital signature
More information about the hlfs-dev