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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15421 in the body.
You can then email your comments to 15421 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: bug-coreutils <at> gnu.org
Subject: RFE: 'id +NNN' for getting group data from a uid rather than username
Date: Thu, 19 Sep 2013 13:13:17 -0600

[Message part 1 (text/plain, inline)]

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

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'.

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

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 15421 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15421 <at> debbugs.gnu.org
Subject: Re: bug#15421: RFE: 'id +NNN' for getting group data from a uid rather
 than username
Date: Thu, 19 Sep 2013 20:24:21 +0100

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
> 
> 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.

cheers,
Pádraig.

Message #11 received at 15421 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 15421 <at> debbugs.gnu.org
Subject: Re: bug#15421: RFE: 'id +NNN' for getting group data from a uid rather
 than username
Date: Thu, 19 Sep 2013 13:35:12 -0600

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #14 received at 15421 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15421 <at> debbugs.gnu.org
Subject: Re: bug#15421: RFE: 'id +NNN' for getting group data from a uid rather
 than username
Date: Thu, 19 Sep 2013 20:39:24 +0100

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.

Message #17 received at 15421 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15421 <at> debbugs.gnu.org
Subject: Re: bug#15421: RFE: 'id +NNN' for getting group data from a uid
 rather than username
Date: Thu, 19 Sep 2013 12:41:24 -0700

On Thu, Sep 19, 2013 at 12:13 PM, Eric Blake <eblake <at> redhat.com> 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
>
> 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'.

Makes sense, and like the chown "feature", it should be safe.

Message #20 received at 15421 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 15421 <at> debbugs.gnu.org
Subject: Re: bug#15421: RFE: 'id +NNN' for getting group data from a uid
 rather than username
Date: Thu, 19 Sep 2013 17:00:55 -0600

Eric Blake wrote:
> > Eric Blake wrote:
> >> I just created a local user named "0" (don't ask), and noticed that

I see nothing wrong with that.  Or a user named "42" either.

> >> 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.

How is "root" hidden by having a user "0" created?

To be clear I have no objection about the proposed functionality.  I
am just pedantically objecting that having a numeric name hides
anything.

> >> $ 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

Exactly.  User "0" does not hide "root".  This is just orthogonal
functionality that had not previously existed.

  $ id root
  uid=0(root) gid=0(root) groups=0(root)
  $ id 0
  id: 0: no such user

There is however 'getent'.

  $ getent passwd 0
  root:x:0:0:root:/root:/bin/bash

  $ getent passwd 0 | awk -F: '{print$1}'
  root

> >> Of course, everyone "knows" that uid 0 is named "root", but this

It is a convention that if changed would cause endless needless
problems.  Renaming "root" to say "superuser" (or "admin") should work
okay in principle.  Except that we would find endless scripts that
look for "root" instead of uid==0 and it just isn't worth the trouble
to break the convention of using the user named "root".

> >> 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'.

It is okay with me if additional functionality is added to use numbers
directly.  I have no objection.  For chown there is direct utility.  I
haven't run across a case where I needed it in id.  I would have used
getent if there were.  But I don't see any problem with adding the
direct use of id number functionality to id.

> 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.

At first glance I see no backward compatibility issues.

Bob

Message #25 received at 15421-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15421-done <at> debbugs.gnu.org
Subject: Re: bug#15421: RFE: 'id +NNN' for getting group data from a uid rather
 than username
Date: Fri, 20 Sep 2013 13:01:10 +0100

[Message part 1 (text/plain, inline)]

On 09/19/2013 08: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
>>
>> 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.

The attached should address this, in combination with:
http://lists.gnu.org/archive/html/bug-gnulib/2013-09/msg00043.html

thanks,
Pádraig.

[id-uid.patch (text/x-patch, attachment)]

Message #28 received at 15421-done <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Eric Blake <eblake <at> redhat.com>
Cc: 15421-done <at> debbugs.gnu.org
Subject: Re: bug#15421: RFE: 'id +NNN' for getting group data from a uid
 rather than username
Date: Fri, 20 Sep 2013 15:24:59 +0200 (CEST)

> On September 20, 2013 at 2:01 PM Pádraig Brady <P <at> draigBrady.com> wrote:
> The attached should address this, in combination with:
> http://lists.gnu.org/archive/html/bug-gnulib/2013-09/msg00043.html

The patch looks good.
Minor nit: maybe pw_name should be IF_LINT(free())d ... which
would require to remove the const qualifier on pw_name.

Thanks & have a nice day,
Berny

Message #31 received at 15421 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Eric Blake <eblake <at> redhat.com>, 15421 <at> debbugs.gnu.org
Subject: Re: bug#15421: RFE: 'id +NNN' for getting group data from a uid rather
 than username
Date: Fri, 20 Sep 2013 14:45:53 +0100

On 09/20/2013 02:24 PM, Bernhard Voelker wrote:
>>  On September 20, 2013 at 2:01 PM Pádraig Brady <P <at> draigBrady.com> wrote:
>>  The attached should address this, in combination with:
>>  http://lists.gnu.org/archive/html/bug-gnulib/2013-09/msg00043.html
> 
> The patch looks good.
> Minor nit: maybe pw_name should be IF_LINT(free())d ... which
> would require to remove the const qualifier on pw_name.

Excellent, Done.
That gets rid of a valgrind "definitely lost" warning.

thanks,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.