Date: Sat, 5 Mar 2011 13:25:36 -0800 From: Kees Cook <kees@...ntu.com> To: Dan Rosenberg <dan.j.rosenberg@...il.com> Cc: oss-security@...ts.openwall.com, Ludwig Nussel <ludwig.nussel@...e.de>, security <security@...ntu.com>, security@...ian.org, secalert@...hat.com, security@...e.de Subject: Re: Suid mount helpers fail to anticipate RLIMIT_FSIZE Hi Dan, On Sat, Mar 05, 2011 at 01:57:41PM -0500, Dan Rosenberg wrote: > This is all good to know, but what do we think is the best way to > actually fix this specific issue for all the systems supported by > distros that are using older versions of util-linux, or for various > other reasons can't get rid of /etc/mtab? > > Fixing every suid mount helper individually seems a bit tedious, but > there might not be a way around it. > [...] > There are a few possible options We could patch glibc to try to > raise the rlimit in addmntent(). Or we could fix every suid mount > helper to raise the rlimit or have proper error handling for the case > when addmntent() fails. This final option requires that mtab editing > be done in a temporary file and aborted on failure, which isn't the > case for all helpers. It seems like fixing glibc to either raise the rlimit or correctly handle the error condition is the way to go (as you already mentioned). I share the concern of the helpers maybe not checking addmntent() return codes, though. If they all do, I would think that just correct error handling in glibc would be accepted upstream. Whatever the fix, it really feels like it should be in glibc. It is what is responsible for actually writing to the file... -Kees -- Kees Cook Ubuntu Security Team
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.