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

[Eric Blake]

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature