Hi

On Thu, Mar 14, 2013 at 09:14:21AM +1100, Craig Small wrote:
> On Wed, Mar 13, 2013 at 12:38:40PM +0000, Karl E. Jorgensen wrote:
> > We found that under the following circumstances:
> > * Kernel > 3.2.29 (which shows > 32 groups in /proc/${pid}/status)
> > * one or more users logged in with lots of supplementary groups
> Hi Karl,
>   Can you look at the change at
> https://www.gitorious.org/procps/procps/commit/7933435584aa1fd75460f4c7715a3d4855d97c1c

That patch looks good - obviously others have had the same idea as me
then :-)

> and see if that fixes (or rather works-around) the problem? The patch
> used 4k not 8k but:

Yeah - I may have gone slightly over the top by jumping to 8k.

> > karl@someserver: ~$ wc --bytes < /proc/1997/status
> > 1810
> 
> that appears to be ok for now.

Yes - but the current ps still appears to choke on it.  And it's
uncomfortably close to 2k, thus making chose at least 4k. Which
paranoia then bumped to 8k.

> > I have a (temporary) patch which increases the buffer size to 8K,
> > which appears sufficient in our case. But this does not fix the
> > underlying problem of having a limited buffer size to start with...
> You're correct, it shouldn't be a statically defined number. It's a
> buffer overflow because the read in file2str protects it but the
> subsequent structure may be a little sad.

I may be misreading you here, but I don't think this is a buffer
overflow. As far as I can see, file2str() does not fill the buffer
beyond the boundary, but the problem lies in the subsequent code which
assumes that the entire contents of the file is available in the
buffer - in the loop around readproc.c:293 

> 
> I'm thinking a size for 32 groups with a realloc/read loop might 
> be the way to go.

Absolutely.  I started working on a patch for that but realised that
this would take longer than I had available.

I have come to realise that readproc.c makes LOTS of assumptions about
the contents of /proc/$pid/status - if the kernel decides to miss a
space somewhere, turn spaces into tabs (or vice versa), the whole
thing collapses, possibly accompanied by noises like SIGSEGV and similar.

Then I heard of procps-ng, decided to investigate it further... and
life got in the way :-S

-- 
Karl E. Jorgensen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to