ZFS user/group quotas & space accounting [PSARC/2009/204 FastTrack timeout 04/08/2009]

[Matthew Ahrens]

Nicolas Williams wrote:
> On Mon, Mar 30, 2009 at 08:39:05PM -0700, Matthew Ahrens wrote:
>> The <user> or <group> is specified using one of the following forms:
>> posix name (eg. ahrens)
>> posix numeric id (eg. 126829)
>> sid name (eg. ahrens at sun)
>> sid numeric id (eg. S-1-12345-12423-125829)
> 
> It's worth noting that the third user/group form ("sid name") could be
> resolved either via getpwnam(3C)/getgrnam(3C) or by using ID mapping
> APIs.  The former requires that nss_ad(5) be used as a backend for
> passwd and group in nsswitch.conf(4), which makes it somewhat not
> friendly.
> 
> In spite of this ISTM that using getpwnam(3C)/getgrnam(3C) is arguably
> more correct.  Yes, any resulting ephemeral UIDs/GIDs have to then be
> mapped back to SIDs via ID mapping APIs, 

But if the system has not been configured in that way (using nss_ad), then 
this getpwnam() would simply fail, which doesn't seem very useful.  Unless 
I'm misunderstanding.  How would getpwnam() return an ephemeral UID?  Does it 
fake up a struct passwd entry?  Does it do that if you don't use nss_ad?

The goal here is to implement a symmetric user interface:

"zfs userspace" tells you the actual sid name (or domain+rid with -n) that is 
being charged (computed from the ZFS FUID).  The user should be able to set 
quotas on that value with "zfs set userquota@<thing-from-zfs-userspace>=<quota>".

I suppose you could argue that if they didn't set up nss_ad, then we should 
not be able to map the domain+rid to a sid name, so they would only see 
domain+rid, and be able to set quotas using that same domain+rid.  But it 
doesn't seem very helpful to make the user run idmap(1m) to do the mapping 
themself.

 > but presumably this happens in
> the "posix numeric id" ID case too if the given ID is an ephemeral ID
> (or is that not allowed?  and if so, why?).

Yes, this is done by idmap_get_sidby[ug]id().

> The issue: how should system components resolve name at domain user/group
> name forms?  Via getXbyname()?  Or via Solaris ID mapping APIs?

Indeed.  It would be great to have one library function to resolve <string 
user identifier> -> S-1-numeric-domain + rid.  (With a NULL domain in the 
case that it's a POSIX id.) In the absence of that, the current algorithm is:

if there's an '@' in the name:
	sid_to_id()
	idmap_get_sidby[ug]id()
else:
	getpwnam()/getgrnam()

Note that in the '@' case, we are translating from user at domain -> (possibly 
ephemeral) UID -> S-1-numeric-domain + rid.  This is pretty roundabout, so we 
have filed RFE 6816841 to provide a more direct interface to map user at domain 
-> S-1-numeric-domain + rid.

Similarly, when printing SIDs from "zfs userspace, we translate from 
S-1-numeric-domain + rid to user at domain by doing sid_to_id() and then 
idmap_getwinnameby[ug]id().  The new interfaces provided by 6816841 will 
simplify this.

> I'm not sure this matters much for now.  I doubt there's much use of '@'
> in user/group names outside the context of nss_ad/ID mapping.  And I
> believe any future cross-Unix domain ID mapping ought to fit into the
> existing Solaris ID mapping framework, so that using existing Solaris ID
> mapping APIs should be future-proof.

Indeed, it would be great if that functionality was available.  If you have 
suggestions on how I could improve our algorithm using currently-available 
interfaces, let me know.

--matt