[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15421: RFE: 'id +NNN' for getting group data from a uid rather than
From: |
Bob Proulx |
Subject: |
bug#15421: RFE: 'id +NNN' for getting group data from a uid rather than username |
Date: |
Thu, 19 Sep 2013 17:00:55 -0600 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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