GNU bug report logs - #15945
chown: accept "[NUMERIC-ID]:" syntax

Previous Next

To reply to this bug, email your comments to 15945 AT debbugs.gnu.org.

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

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

From: Tormen <quickhelp <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: chown: Does now allow setting user and users login group with
 numerical user ID
Date: Thu, 21 Nov 2013 12:50:40 +0100

Dear Gnu Team,

First off: Thanks for existing!! :)))

I think I just found a bug in chown... \o/ ;)

Details about my GNU/Linux system:
	Debian wheezy stable 7.2

	dpkg -S /bin/chown
	coreutils: /bin/chown

	dpkg -l|grep coreutils
	ii  coreutils      8.13-3.5    amd64   GNU core utilities

	uname -a
	Linux seven 3.10-0.bpo.3-amd64 #1 SMP Debian 3.10.11-1~bpo70+1
(2013-09-24) x86_64 GNU/Linux

	echo $SHELL
	/bin/zsh

I tried:
	chown 1001: /tmp/bla

Leading to:
	chown: invalid spec: `1001:'

But as 1001 == "me", it should have done a:
	chown me: /tmp/bla
(which works just fine).

Is this a bug or a feature ?

... it should be a bug except if there is a technical detail I am
missing here.

Best,

Tormen

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

From: Eric Blake <eblake <at> redhat.com>
To: Tormen <quickhelp <at> gmail.com>, 15945-done <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 08:53:47 -0700

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

tag 15945 notabug
thanks

On 11/21/2013 04:50 AM, Tormen wrote:

> 
> I think I just found a bug in chown... \o/ ;)
> 
> I tried:
> 	chown 1001: /tmp/bla
> 
> Leading to:
> 	chown: invalid spec: `1001:'

Drop the trailing colon.

> ... it should be a bug except if there is a technical detail I am
> missing here.

If you provide a colon, you MUST also provide a group spec.  Per 'chown
--help', the syntax is:
 chown [OPTION]...  [OWNER][:[GROUP]] FILE...
so these are valid:
 chown 1001 /tmp/bla        # change owner only
 chown :1001 /tmp/bla       # change group only
 chown 1001:1001 /tmp/bla   # change both
but this is invalid:
 chown 1001: /tmp/bla       # '' is not a valid group

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

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

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

From: Eric Blake <eblake <at> redhat.com>
To: 15945 <at> debbugs.gnu.org, quickhelp <at> gmail.com
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 09:09:34 -0700

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

On 11/21/2013 08:53 AM, Eric Blake wrote:
> If you provide a colon, you MUST also provide a group spec.  Per 'chown
> --help', the syntax is:
>  chown [OPTION]... [OWNER][:[GROUP]] FILE...

Hmm, on re-reading this, I think we have two bugs in our help syntax.
The major bug is that we document [GROUP] as optional, but in reality it
is mandatory if ':' is present.  So we definitely need to change
'[:[GROUP]]' to '[:GROUP]'.

The minor group stems from a GNU extension.  POSIX requires that the
OWNER portion is mandatory:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chown.html

But as a GNU extension, we allow it to be empty to allow for:

>  chown :1001 /tmp/bla       # change group only

But as written, the usage text implies that we can omit both OWNER and
:GROUP and still have a valid call, as in:

chown /tmp/bla

which isn't quite true.  Alas, the only way I can see to rewrite the
fact that SOME spec is necessary, while still highlighting the GNU
extension of omitting OWNER, is to split the usage into two lines:

Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
  or:  chown [OPTION]... :GROUP FILE...

Thoughts?  Should we reopen this bug to track the doc bug[s]?

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

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

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

From: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
To: 15945 <at> debbugs.gnu.org, eblake <at> redhat.com, quickhelp <at> gmail.com
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 17:10:54 +0100

Hi,

On Thu, Nov 21, 2013 at 08:53:47AM -0700, Eric Blake wrote:
> On 11/21/2013 04:50 AM, Tormen wrote:
> > 
> > I think I just found a bug in chown... \o/ ;)
> > 
> > I tried:
> > 	chown 1001: /tmp/bla
> > 
> > Leading to:
> > 	chown: invalid spec: `1001:'
> 
> Drop the trailing colon.
> 
> > ... it should be a bug except if there is a technical detail I am
> > missing here.
> 
> If you provide a colon, you MUST also provide a group spec.  Per 'chown
> --help', the syntax is:
>  chown [OPTION]...  [OWNER][:[GROUP]] FILE...
> so these are valid:
>  chown 1001 /tmp/bla        # change owner only
>  chown :1001 /tmp/bla       # change group only
>  chown 1001:1001 /tmp/bla   # change both
> but this is invalid:
>  chown 1001: /tmp/bla       # '' is not a valid group

Should this be changed to 'chown [OPTION]...  [OWNER][:GROUP] FILE...'
then?

Erik

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

From: Tormen <quickhelp <at> gmail.com>
To: 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: closed (Re: bug#15945: chown: Does now allow setting
 user and users login group with numerical user ID)
Date: Thu, 21 Nov 2013 17:14:44 +0100

Dear GNU team,

But why is not possible for "chown 1001: /tmp/bla"
to resolve 1001 to "me"
and then do the same than "chown me: /tmp/bla" ?

(I guess internally chown will do the reverse lookup (me -> 1001), when
performing a "chown me: /tmp/bla")

Could you please be so kind to explain the "why not" ?


==============================================


Wording in "man chown":

DESCRIPTION
       This manual page documents the GNU version of chown.  chown
changes the
       user and/or group ownership of each given file.  If only  an 
owner  (a
       user  name or numeric user ID) is given, that user is made the
owner of
       each given file, and the files' group is not changed.  [1] If the
owner  is
       followed  by  a  colon  and a group name (or numeric group ID),
with no
       spaces between them, the group ownership of the  files  is 
changed  as
       well.  [2] If a colon but no group name follows the user name,
that user is
       made the owner of the files and the group of the files  is 
changed  to
       that  user's  login  group.   If the colon and group are given,
but the
       owner is omitted, only the group of the files is changed; in this
case,
       chown  performs  the same function as chgrp.  If only a colon is
given,
       or if the entire operand is empty, neither the owner nor the 
group  is
       changed.

[1] At this point "owner" is referenced as "name or numeric ID".

[2] At this point you do not reprecise "owner" but only state about the
additional colon ":" -- so one must expect "owner" still to be "name or
numeric ID".


Best,

Tormen


On 21/11/13 16:54, GNU bug Tracking System wrote:
> Your bug report
>
> #15945: chown: Does now allow setting user and users login group with numerical user ID
>
> which was filed against the coreutils package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 15945 <at> debbugs.gnu.org.
>

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

From: Tormen <quickhelp <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15945-done <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 17:24:25 +0100

Hi again,

Sorry, I don't know why, but I missed this part of your answer:

On 21/11/13 16:53, Eric Blake wrote:
>> I think I just found a bug in chown... \o/ ;)
>>
>> I tried:
>> 	chown 1001: /tmp/bla
>>
>> Leading to:
>> 	chown: invalid spec: `1001:'
> Drop the trailing colon.
But I want the same effect than
    chown me: /tmp/bla
so changing:
    (1) the owner of /tmp/bla to user "me"
    (2) the group of /tmp/bla to the login-group of user "me"

    chown me /tmp/bla
should only do (1), no ?


> If you provide a colon, you MUST also provide a group spec.  Per 'chown
> --help', the syntax is:
>  chown [OPTION]...  [OWNER][:[GROUP]] FILE...
> so these are valid:
>  chown 1001 /tmp/bla        # change owner only
>  chown :1001 /tmp/bla       # change group only
>  chown 1001:1001 /tmp/bla   # change both
> but this is invalid:
>  chown 1001: /tmp/bla       # '' is not a valid group
Yes, but when you execute:
    chown me: /tmp/bla

as group is '' as well and it is not a problem.

I don't see any problem / ambiguity in allowing both:
    chown me: /tmp/bla
    chown 1001: /tmp/bla

especially as:
    chown me /tmp/bla
    chown 1001 /tmp/bla
are both possible and provide the same result.

So for the trailing ":" case it should be (flexibly/convieniently) work
the same, no ?

Tormen

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

From: Eric Blake <eblake <at> redhat.com>
To: Tormen <quickhelp <at> gmail.com>
Cc: 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 09:32:25 -0700

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

tag 15945 - notabug
reopen 15945
thanks

On 11/21/2013 09:24 AM, Tormen wrote:

>>> Leading to:
>>> 	chown: invalid spec: `1001:'
>> Drop the trailing colon.
> But I want the same effect than
>     chown me: /tmp/bla

Ooh, you're right.  We DO document that:

OWNER':'GROUP
     If the OWNER is followed by a colon and a GROUP (a group name or
     numeric group ID), with no spaces between them, the group ownership
     of the files is changed as well (to GROUP).

OWNER':'
     If a colon but no group name follows OWNER, that user is made the
     owner of the files and the group of the files is changed to OWNER's
     login group.

so it looks like we have a bug that if OWNER is numeric, we aren't
looking up OWNER's login group.

Which means my earlier comments aren't quite correct - the existing use
of [:[GROUP]] in usage text is correct.  But I _still_ think we need to
split into two lines to make it obvious that the argument itself is
mandatory, as in:

Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
  or:  chown [OPTION]... :[GROUP] FILE...

or even rewrite it along the lines of the info page:

Usage: chown [OPTION]... NEWSPEC FILE...

and document that NEWSPEC is [OWNER][:[GROUP]]

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

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

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

From: Tormen <quickhelp <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 17:36:14 +0100

On 21/11/13 17:09, Eric Blake wrote:
> But as written, the usage text implies that we can omit both OWNER and
> :GROUP and still have a valid call, as in:
>
> chown /tmp/bla
>
> which isn't quite true.  Alas, the only way I can see to rewrite the
> fact that SOME spec is necessary, while still highlighting the GNU
> extension of omitting OWNER, is to split the usage into two lines:
>
> Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
>   or:  chown [OPTION]... :GROUP FILE...
>
> Thoughts?  Should we reopen this bug to track the doc bug[s]?
>
> Alas, ...
Hehe.

I agree, two lines should be the only way to express that
there are 4 possibilities:
    chown OWNER
    chown OWNER:
    chown OWNER:GROUP
    chwon :GROUP

But shouldn't all 4 possibilities allow both OWNER and GROUP to be
specified either as NAME or as numerical ID ?

    chown OWNERNAME           == chown OWNERID    [*]
    chown OWNERNAME:          == chown OWNERID:   [**]
    chown OWNERNAME:GROUPNAME == chown OWNERID:GROUPID[*]
    chwon :GROUPNAME          ==chown :GROUPID [*]

[*] working as expected
[**] NOT working as expected (see my bug report) ... but why ?

Especially as:
    chown 1001:mine /tmp/bla
and
    chown me:1001 /tmp/bla
works fine!

(with mine == 1001)


Tormen

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

From: Tormen <quickhelp <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 17:41:19 +0100

On 21/11/13 17:32, Eric Blake wrote:
> tag 15945 - notabug
> reopen 15945
> thanks
No, thank you :)

> On 11/21/2013 09:24 AM, Tormen wrote:
>
>>>> Leading to:
>>>> 	chown: invalid spec: `1001:'
>>> Drop the trailing colon.
>> But I want the same effect than
>>     chown me: /tmp/bla
> Ooh, you're right.  We DO document that:
I started wondering if I missed something extremely obvious here ;)

> Which means my earlier comments aren't quite correct - the existing use
> of [:[GROUP]] in usage text is correct.  But I _still_ think we need to
> split into two lines to make it obvious that the argument itself is
> mandatory, as in:
>
> Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
>   or:  chown [OPTION]... :[GROUP] FILE...
>
> or even rewrite it along the lines of the info page:
>
> Usage: chown [OPTION]... NEWSPEC FILE...
>
> and document that NEWSPEC is [OWNER][:[GROUP]]
... and mention that either OWNER or GROUP needs to be present ;)

But I prefer the 2 lines ... more concise and allows to quickly grasp
the meaning (IMHO).

Tormen

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

From: Eric Blake <eblake <at> redhat.com>
To: Tormen <quickhelp <at> gmail.com>
Cc: 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 09:44:02 -0700

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

On 11/21/2013 09:41 AM, Tormen wrote:
>>> But I want the same effect than
>>>     chown me: /tmp/bla
>> Ooh, you're right.  We DO document that:
> I started wondering if I missed something extremely obvious here ;)

No, rather _I_ missed that 'chown --help' is (intentionally) not as
comprehensive as 'info coreutils chown' :)

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

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

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

From: Tormen <quickhelp <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 17:46:46 +0100

On 21/11/13 17:44, Eric Blake wrote:
> On 11/21/2013 09:41 AM, Tormen wrote:
>>>> But I want the same effect than
>>>>     chown me: /tmp/bla
>>> Ooh, you're right.  We DO document that:
>> I started wondering if I missed something extremely obvious here ;)
> No, rather _I_ missed that 'chown --help' is (intentionally) not as
> comprehensive as 'info coreutils chown' :)
>
I wonder how old the bug is (my "bug-hunters pride" talking)...

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

From: Bob Proulx <bob <at> proulx.com>
To: 15945 <at> debbugs.gnu.org
Cc: Tormen <quickhelp <at> gmail.com>
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 09:47:23 -0700

Eric Blake wrote:
> OWNER':'
>      If a colon but no group name follows OWNER, that user is made the
>      owner of the files and the group of the files is changed to OWNER's
>      login group.

Long ago this was an existing behavior of GNU rm and discussion on the
list talked of removing it.  I defended it because I often used this
on various systems to set the default group of a user.  Because some
systems are configured with user-private-groups where the user is in a
private group while on other systems the user is in a shared "users"
group.  Using 'chown foo: file' was a nice way to set the group to
foo's default group without needing to figure out what that group was
ahead of time.  I don't know when it was introduced into GNU chown but
at the least I had been using it extensively.

> so it looks like we have a bug that if OWNER is numeric, we aren't
> looking up OWNER's login group.

Seems that way.

Bob

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

From: Bob Proulx <bob <at> proulx.com>
To: 15945 <at> debbugs.gnu.org
Cc: Tormen <quickhelp <at> gmail.com>
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 09:49:55 -0700

Bob Proulx wrote:
> Long ago this was an existing behavior of GNU rm and discussion on the

  s/rm/chown/

Argh!  The recent 'rm' discussion clouded my typing.  I meant 'chown' there.

Bob

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: Tormen <quickhelp <at> gmail.com>, 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 18:45:06 +0100

Eric Blake <eblake <at> redhat.com> writes:

> so it looks like we have a bug that if OWNER is numeric, we aren't
> looking up OWNER's login group.

There may not be a unique uid to user name mapping.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Eric Blake <eblake <at> redhat.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Tormen <quickhelp <at> gmail.com>, 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 10:47:12 -0700

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

On 11/21/2013 10:45 AM, Andreas Schwab wrote:
> Eric Blake <eblake <at> redhat.com> writes:
> 
>> so it looks like we have a bug that if OWNER is numeric, we aren't
>> looking up OWNER's login group.
> 
> There may not be a unique uid to user name mapping.

Right, but in that case, the error message should make sense.  Rather
than being a blanket "invalid spec: `1001:'" it should say something
like "unable to determine default group for user `1001'"

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

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

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

From: Bob Proulx <bob <at> proulx.com>
To: 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 11:01:44 -0700

Andreas Schwab wrote:
> Eric Blake writes:
> > so it looks like we have a bug that if OWNER is numeric, we aren't
> > looking up OWNER's login group.
> 
> There may not be a unique uid to user name mapping.

I think that anyone using this would expect it would take the first
one returned.  The same that happens right now in a "normal" system.
The same name that 'ls -l' would return.  We don't worry that 'ls -l'
might be mapping a name that might not be unique and shouldn't here
either.

I realize that 'nscd' breaks that long standing assumption that order
matters by returning one randomly.  I consider that a bug in nscd.

Bob

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

From: Tormen <quickhelp <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 19:07:59 +0100

On 21/11/13 18:47, Eric Blake wrote:
> On 11/21/2013 10:45 AM, Andreas Schwab wrote:
>> Eric Blake <eblake <at> redhat.com> writes:
>>
>>> so it looks like we have a bug that if OWNER is numeric, we aren't
>>> looking up OWNER's login group.
>> There may not be a unique uid to user name mapping.
Interesting. But I guess the ID (for owner and group) is what is stored
in the filesystem
(as you can rename users and the ID stays the same on the file).
In which case there is no tranlsation (ID -> name) necessary when
calling chown with an uid.
The "ls" then does the lookup to translate the ID in a name then.
And so the ls could run into the mapping problem...  or chown if called
with a username.

Or is it the other way round ?

> Right, but in that case, the error message should make sense.  Rather
> than being a blanket "invalid spec: `1001:'" it should say something
> like "unable to determine default group for user `1001'"
>
So in no case there should be a mapping problem when using numerical IDs
for users/groups.
Only when called with names.

In any case, in my case the mapping is unique:

grep 1001 /etc/passwd
me:x:1001:1001:This is Me,,,:/home/me:/bin/zsh

:)


Tormen

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

From: Eric Blake <eblake <at> redhat.com>
To: Tormen <quickhelp <at> gmail.com>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Thu, 21 Nov 2013 13:53:37 -0700

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

On 11/21/2013 11:07 AM, Tormen wrote:

>>> There may not be a unique uid to user name mapping.
> Interesting. But I guess the ID (for owner and group) is what is stored
> in the filesystem
> (as you can rename users and the ID stays the same on the file).
> In which case there is no tranlsation (ID -> name) necessary when
> calling chown with an uid.
> The "ls" then does the lookup to translate the ID in a name then.
> And so the ls could run into the mapping problem...  or chown if called
> with a username.
> 
> Or is it the other way round ?

No, you have it right - stat() stores only uid, and ls(1) does a name
lookup for printing "the" (more precisely, "a") username associated with
that id.

>> Right, but in that case, the error message should make sense.  Rather
>> than being a blanket "invalid spec: `1001:'" it should say something
>> like "unable to determine default group for user `1001'"
>>
> So in no case there should be a mapping problem when using numerical IDs
> for users/groups.
> Only when called with names.

Not true - we still have two potential lookup problems.  One is that
that there may be NO name associated with ID (ls -l just falls back to
listing id, but in the chmod case, we can't do a default login group
lookup if we don't have a name).  Try as root:

# touch /tmp/f
# chown 12345 /tmp/f
# ls -l /tmp/f
-rw-r--r--. 1 12345 root 0 Nov 21 13:51 /tmp/f

The other is that even if a name is associated with an ID (whether the
only name, or whether the first name out of multiple that map to the
id), the default login group lookup for that name may fail (but that's
true even if we didn't first do a uid->name lookup).

Either way, my point remains - we should have a saner error message if
we are unable to determine a default login group for a given user
identification, rather than just declaring the entire '1001:' an invalid
spec.

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

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

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

From: Tormen <quickhelp <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 15945 <at> debbugs.gnu.org
Subject: Re: bug#15945: chown: Does now allow setting user and users login
 group with numerical user ID
Date: Fri, 22 Nov 2013 01:06:06 +0100

Thanks a lot for explaining!!

On 21/11/13 21:53, Eric Blake wrote:
>>> Right, but in that case, the error message should make sense.  Rather
>>> than being a blanket "invalid spec: `1001:'" it should say something
>>> like "unable to determine default group for user `1001'"
>>>
>> So in no case there should be a mapping problem when using numerical IDs
>> for users/groups.
>> Only when called with names.
> Not true - we still have two potential lookup problems.  One is that
> that there may be NO name associated with ID (ls -l just falls back to
> listing id, but in the chmod case, we can't do a default login group
> lookup if we don't have a name).
Yes of course for the login group lookup needs the name! - Dough.
> Either way, my point remains - we should have a saner error message if
> we are unable to determine a default login group for a given user
> identification, rather than just declaring the entire '1001:' an invalid
> spec.
+1 for the nice error message :)

Previous Next

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