[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=viGP4Jr4reOz4ceS=rtSFuMnw7Q@mail.gmail.com>
Date: Wed, 27 Apr 2011 11:00:16 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: Tomas Hoger <thoger@...hat.com>
Cc: oss-security@...ts.openwall.com, Ludwig Nussel <ludwig.nussel@...e.de>,
Petr Baudis <pasky@...e.cz>
Subject: Re: Suid mount helpers fail to anticipate RLIMIT_FSIZE
On Wed, Apr 27, 2011 at 10:56 AM, Tomas Hoger <thoger@...hat.com> wrote:
> On Tue, 15 Mar 2011 09:13:00 -0400 Dan Rosenberg wrote:
>
>> util-linux mount
>> =============
>> * Edits /etc/mtab.tmp with custom my_addmntent(), behaves identically
>> to glibc addmntent() in terms of return code
>> * Succeeds on partial writes, does not remove temp file on failure
>> (could result in additional corruption of /etc/mtab through multiple
>> invocations), does not remove lock file /etc/mtab~ on failure (also an
>> issue)
>
> Dan, would you mind clarifying the way to achieve mtab corruption via
> truncated left-over mtab.tmp file and multiple invocations? After some
> discussion with our util-linux maintainer, we fail to see an obvious
> way. util-linux opens mtab.tmp using "w" fopen open, i.e. using O_TRUNC
> open flag. So if there's any mtab.tmp file found, it's overwritten and
> its existence does not block further use of mount / umount as existence
> of mtab~ lock file does.
>
Ah, quite right. I missed that since I was just doing a quick survey
of a bunch of helpers. It seems the mtab.tmp file isn't an issue.
Thanks for looking into it.
-Dan
> Thank you!
>
> --
> Tomas Hoger / Red Hat Security Response 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.
