bug#15421: RFE: 'id +NNN' for getting group data from a uid rather than username

[Pádraig Brady]

On 09/19/2013 08:35 PM, Eric Blake wrote:
> On 09/19/2013 01:24 PM, Pádraig Brady wrote:
>> On 09/19/2013 08:13 PM, Eric Blake wrote:
>>> I just created a local user named "0" (don't ask), and noticed that
>>> although we can do things like "chown +0:+0 file" to FORCE a file to be
>>> owned by uid 0 (rather than the uid of my unfortunate "0" username),
>>> it's a bit harder to learn details about a uid hidden by a poor username.
>>>
>>> $ id 0
>>> uid=14987(0) gid=14987(0) groups=14987(0)
>>> $ id +0
>>> id: +0: no such user
> 
> $ id 14987
> id: 14987: no such user
> 
>>>
>>> Of course, everyone "knows" that uid 0 is named "root", but this
>>> question applies to any other unfortunate uid/name collision.
>>> Therefore, I propose that we support 'id +0' as the way to say 'give me
>>> the details about uid 0, no matter if username 0 also happens to exist'.
>>
>> Yep that makes sense.
>> I see also that FreeBSD does this too.
>> I'll do that tonight.
> 
> For that matter, should 'id 0' behave like 'chown 0 file', where it
> tries a username lookup first, and falls back to a uid parse?  That is,
> the '+0' form is useful for forcing a uid lookup, but I _like_ the
> usability aspect of doing a name lookup by default with a fallback to
> uid lookup, rather than requiring that id operate on name only.
> 
> In other words, I suspect we should be reusing some common code between
> chown, id, and any other program that takes user identities as input, so
> that in the common case of no name/uid collisions, typing a plain number
> is still useful for its uid aspect without having to type a prepended +
> just to force a uid lookup.

Yes exactly.
We'd need to do that for compat anyway.

cheers,
Pádraig.