proposed new Unix QFS Info level

James Peach jpeach at
Wed Feb 7 06:23:23 GMT 2007

On 06/02/2007, at 10:10 PM, Conrad Minshall wrote:

> At 2:10 PM -0800 2/6/07, James Peach wrote:
>> I'd prefer not to nail down the relationships between the SIDs and  
>> the
>> GIDs in this case. For example, on Mac OS X, it's very hard to
>> guarantee that the GID list is complete - the kernel only knows a
>> small number of the group memberships at any one time. Since the  
>> group
>> memberships can (potentially) change at any time, this information is
>> best regarded as a hint and used for display purposes (ie. not for
>> access control).
>> Additionally, it is possible for a server to not map any of the GIDs.
>> For example, there may be a server that provides *only* Unix
>> semantics. In this case, the GID list oule be populated and the SID
>> list would not be. I don't know of any such servers, but there was a
>> desire to make this possible :)
>> The main rationale for this extension is for Unix clients to be able
>> to sensibly display whether files are "owned by me" or "owned by
>> someone else, as per "ls -l". A secondary rationale is to be able to
>> determine whether a client has been mapped or forced to guest on a
>> per-share basis. This can happen with some Samba configurations.
> OK, so I must ask why should this (Unix "whoami" proposal aka  
> QFSInfo level 0x202) return all those supplementary gids and SIDs  
> at all? The latency cost could be considerable.

If it's very expensive to gather this on the server, then the server  
is free to omit the GID and SID lists. Alternatively, a server could  
provide partial lists based on whatever information it has cached at  
the time. It's very much a "best effort" response.

This is primarily intended as a low-cost way for a Unix client to  
improve the presentation of Unix permissions. The main things that  
are needed for an improved client experience are the guest flag, and  
primary UID and GID. The rest is just icing that is (in theory) nice  
to have.

James Peach | jpeach at

More information about the samba-technical mailing list