Re: fs-independent quotas

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Nov 18, 2011 at 12:55:32AM +0000, David Holland wrote:
> On Thu, Nov 17, 2011 at 05:29:22PM +0100, Manuel Bouyer wrote:
>  > I still believe proplib is better. For example, you can go from a
>  > 32bit to a 64bit uid_t/gid_t without versionning (in the data structure
>  > it's still <integer></integer>).
> 
> NO YOU CAN'T. Sorry for shouting, but this really annoys me.
> 
> Proplib handles all integers internally as intmax_t, so *it* won't get
> confused. (Unless intmax_t gets changed, at which point all
> proplib-using syscalls and ioctls need to be versioned, with no clear
> way to provide compat logic; that won't be pretty.)

And it will also error out if you try to store an integer larger than
the type allow. See prop_dictionary_get_int in prop_dictionary_util.c

> 
> But what happens if you do this and then create a user with e.g. uid
> 2^40, and try to read its quota information out with the 32-bit quota
> utilities? Well, lookee here:
> 
>       showuid((uid_t)atoi(*argv));
> 
> (quota.c line 179)

this has nothing to do with the quotactl interface. Yes, there's still
room for improvements in the tools. History is heavy here.
But you can't use this to shoot down the quotactl interface; these are
2 independant things.

> 
> boom, silent truncation to 32 bits. If you're lucky. atoi() is allowed
> to send you nasal demons in this case, too.
> 
> ok, so maybe that's just a bug. What happens if instead you dump all
> quota information?
> 
>       errx(1, "can't find id in quota entry");
> 
> (repquota.c line 294)
> 
> Not very helpful, ISTM.
> 
> Granted, this is probably not markedly worse than the results if doing
> compat the traditional way; but it's no better, either.

You missed the point.
The point is, on a system where uids still fit in 32bits, I can install
a kernel with a 64bits uid_t and the 32bits quota tools will still work,
without any special backward compat handling in the quotactl interface.
Or I can use quota tools with 64bits uid_t on a kernel with 32bits uid_t,
it will work as well.
Of course, if you start using uids that don't fit in 32bits, you need
a kernel and userland with 64bits. But if you don't *need* 64bits
uid_t, you don't have to update userland because you have a 64bits uid_t
kernel, or vice-versa.

> 
> Sure, you could update all the tools to anticipate this case, and
> dozens or hundreds of other unlikely but potentially possible changes
> like this; or you could just send back structs the traditional way,
> and when the time comes, if it ever does, version the syscall or the
> command codes or whatever in the traditional way. Much less effort
> overall.

No, it's more efforts. With a binary struct, you have to version the syscall
(and handle conversion from old to new format) a whole class of changes,
which are handled automagically by proplib.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--