This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12625] mntent operations provide no indication of failure due to RLIMIT_FSIZE


http://sourceware.org/bugzilla/show_bug.cgi?id=12625

--- Comment #3 from Tomas Hoger <thoger at redhat dot com> 2011-04-18 13:44:08 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > Rather than forcing every setuid mount helper to explicitly alter resource
> > limits prior to calling addmntent(), etc., it would be better if addmntent()
> > attempted to flush and return failure based on the success of the fflush(), as
> > suggested by Tomas Hoger:
> 
> That's completely bogus.  Applications which cannot handle problems introduced
> like this also won't check the return value of addmntent.

This bug is not about fixing apps that don't check addmntent return value via
some glibc-side magic, it is about fixing addmntent to not return success when
mtab update failed (or is going to fail when the buffer is flushed in endmntent
/ fclose), so the applications that do check return value can detect the error.

> Just fix the damned programs which doesn't use the existing interface correctly.

Can you clarify what exactly you refer to as incorrect use of existing
interface?  Even if you check addmntent return value, you can't rely on it. 
endmntent always returns the same value, hence no check is possible there.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]