tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fs-independent quotas



On Thu, Nov 17, 2011 at 03:51:52PM +0100, Manuel Bouyer wrote:
> On Thu, Nov 17, 2011 at 01:02:33PM +0000, David Holland wrote:
> >  > > Neither is good enough if you're providing backwards compatibility;
> >  > 
> >  > An error is still better than a crash.
> > 
> > ...and neither is acceptable for the quotactl system call, either in
> > the kernel processing it or in userlevel processing the returned data.
> > The code has to be right; consequently, what happens if it's wrong is
> > less important or even entirely unimportant.
> 
> and I still believe it's easier to get it right with something like
> prolib (where you have to pass the data you got through problib
> functions), than using ad-hoc checks, that may or may not be used
> by all involved parties.

Here is my concern: I think syntax and semantics are being confused here
in a way that makes it likely we will have a false sense of security
about bugs that could crash the kernel (or lead to severe security
issues, etc).

I do not see how proplib helps at all with bugs caused by syntactically
valid data with semantically invalid values.  This means that the
kernel side code must parse the property list, then check each
value sufficiently to ensure that using those values will not cause
an error (at worst, a crash).

Consider the (very poor) old interface, in which void pointers were
thrown around.  Suppose they pointed at bad addresses?  No system call
should directly dereference pointers passed by userspace, so the user
application should get EFAULT if it passes something that can't copy-in,
end of game.

But suppose that void* actually points at valid user memory that has
insane contents when interpreted as a quota structure?  In that case, I
cannot see why the validity checks required are any more, nor any less,
than those required for the parsed data from the proplib interface.  The
fields have acceptable values, or they don't; if they have insane values
and those values are just used by the kernel and cause a crash, that
consequence should be the same either way -- whether the insane values
came from a property list or from a binary datastructure.

What am I missing?

Thor


Home | Main Index | Thread Index | Old Index