Attaching using username instead of uid fails

[GoogleCodeExporter]

Good evening,

I've been playing around with go9p and libixp (http://repo.cat-v.org/libixp/) 
and I think I spotted a bug when they interact.

To reproduce,
1. launch any of srv/examples on localhost:5640
2. run "ixpc -a 'tcp!127.0.0.1!5640' ls"
3. ixpc fails with "unknown user: 22"

cl and ls in clnt/examples are fine. With -d=1 on the server, I can see that 
they send Tattach messages looking like
Tattach tag 0 fid 0 afid 4294967295 uname '' nuname 1001 aname ''
whereas ixpc does
Tattach tag 0 fid 1 afid 4294967295 uname 'louis' nuname 4294967295 aname ''

I understand that the go9p programs put the nil value in uname and rely on 
nuname and that ixpc does the exact opposite.

I figured out 22 means EINVAL, the invalid user seems to be the 0xFFFFFFFF id. 
As far as I know, this report could also be considered an issue with libixp.

I haven't tried connecting a go9p client and a libixp server over tcp.

Louis

Original issue reported on code.google.com by [email protected] on 23 Jul 2014 at 8:29

[GoogleCodeExporter]

This is caused by changeset 134 -- I don't use dotu for my servers and after 
updating go9p, "9p" from p9p suddenly fails to connect.

Ultimately the problem boils down to the default Users implementation not 
implementing Uname2User.

For my case (non-dotu server & client) I'd be happy to have my server provide a 
custom Users implentation, but this seems like a suboptimal solution for the 
original report (dotu server & non-dotu client).

Original comment by [email protected] on 8 Aug 2014 at 4:43

[GoogleCodeExporter]

The best solution I see that doesn't break backwards compatibility is to have 
osUsers defer to the os/user package. The downside is os/user wasn't 
implemented on all platforms until go 1.1 -- but I think everything was in 
place for linux at 1.0's launch, and the p.Users interface doesn't port very 
well to windows/plan 9 anyway (non-integer UIDs).

Go still doesn't provide an interface to get at the name of a group[1] which 
seems discouraging, but is not that important since user groups are not part of 
the 9p protocol itself - they are a server-side concept.

[1] http://code.google.com/p/go/issues/detail?id=2617

I've attached a patch to that effect.

Original comment by [email protected] on 11 Aug 2014 at 2:00

Attachments:

• go9p-issue30.patch

[vat9]

Use of "os/user" unfortunately means that cross compiling during go build may not work as CGO_ENABLED=1 is required.

[mischief]

closed by #44 ?

[sqweek]

Yes this is fixed, I think by c1542d0 (which was also applied to the code.google.com repo while it was active).