After fixing issue 30 (user lookup) attach in dotu mode no longer works - patch proposed about go9p HOT 7 CLOSED

When .u is used, the numerical uid takes precedence over the uname. I don't 
think it makes sense to use the uname parameter in that case.

My primary use case is to make the 9p server listen on a domain socket, and 
kernel-mount that socket.

So (the server has my patch, "golubovsky" is an existing user): 

$ go-src/bin/ninepserver -addr=/tmp/socket -d=1 -proto=unix -root=.

Mount the socket using 9p2000.u

# mount -t 9p /tmp/socket /mnt/ -o trans=unix,version=9p2000.u,uname=golubovsky

2014/12/05 23:35:43 connected
2014/12/05 23:35:43 >>> @ Tversion tag 65535 msize 8192 version '9P2000.u'
2014/12/05 23:35:43 <<< @ Rversion tag 65535 msize 8192 version '9P2000.u'
2014/12/05 23:35:43 >>> @ Tattach tag 1 fid 0 afid 4294967295 uname 
'golubovsky' nuname 4294967295 aname ''
2014/12/05 23:35:43 <<< @ Rattach tag 1 aqid (4835cc 1a44734e 'd')
2014/12/05 23:35:43 >>> @ Tstat tag 1 fid 0
2014/12/05 23:35:43 <<< @ Rstat tag 1 st ('.' 'golubovsky' 'none' 'none' q 
(4835cc 1a44734e 'd') m d777 at 1417779905 mt 1417779901 l 4096 t 0 d 0 ext )

# mount -t 9p /tmp/socket /mnt/ -o trans=unix,version=9p2000.u,uname=nosuchuser
mount: wrong fs type, bad option, bad superblock on /tmp/socket,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

2014/12/05 23:36:23 connected
2014/12/05 23:36:23 >>> @ Tversion tag 65535 msize 8192 version '9P2000.u'
2014/12/05 23:36:23 <<< @ Rversion tag 65535 msize 8192 version '9P2000.u'
2014/12/05 23:36:23 >>> @ Tattach tag 1 fid 0 afid 4294967295 uname 
'nosuchuser' nuname 4294967295 aname ''
2014/12/05 23:36:23 <<< @ Rerror tag 1 ename 'unknown user: 22' ecode 22
2014/12/05 23:36:23 disconnected

and mount fails.

Note that nuname = -1 in both cases simply because Linux kernel does not pass 
UID to the 9p userspace program.

# mount -t 9p /tmp/socket /mnt/ -o trans=unix,version=9p2000,uname=golubovsky

2014/12/05 23:39:02 connected
2014/12/05 23:39:02 >>> @ Tversion tag 65535 msize 8192 version '9P2000'
2014/12/05 23:39:02 <<< @ Rversion tag 65535 msize 8192 version '9P2000'
2014/12/05 23:39:02 >>> @ Tattach tag 1 fid 0 afid 4294967295 uname 
'golubovsky' nuname 4294967295 aname ''
2014/12/05 23:39:02 <<< @ Rattach tag 1 aqid (4835cc 1a44734e 'd')
2014/12/05 23:39:02 >>> @ Tstat tag 1 fid 0
2014/12/05 23:39:02 <<< @ Rstat tag 1 st ('.' 'golubovsky' 'golubovsky' 'none' 
q (4835cc 1a44734e 'd') m d777 at 1417779905 mt 1417779901 l 4096 t 0 d 0 ext )

# mount -t 9p /tmp/socket /mnt/ -o trans=unix,version=9p2000,uname=nosuchuser
mount: Unknown error 526

2014/12/05 23:39:49 connected
2014/12/05 23:39:49 >>> @ Tversion tag 65535 msize 8192 version '9P2000'
2014/12/05 23:39:49 <<< @ Rversion tag 65535 msize 8192 version '9P2000'
2014/12/05 23:39:49 >>> @ Tattach tag 1 fid 0 afid 4294967295 uname 
'nosuchuser' nuname 4294967295 aname ''
2014/12/05 23:39:49 <<< @ Rerror tag 1 ename 'unknown user: 22' ecode 0
2014/12/05 23:39:49 disconnected

mount fails again, but with different message.

This is Linux 

# uname -a
Linux hpcompaq 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux

So, in both cases, at least with my patch, character user name is in use when 
numeric lookup does not succeed. Without my patch 9p2000 would work but .u 
would not. The reason why I don't want to use 9p2000 is that it also ignores 
files' owner numeric IDs returning -1 for both user and group.

This is more like an issue with the logic of the kernel (which does not want to 
deal with numeric UIDs). This makes sense though because if 9p connection is 
made to a remote system, local numeric UIDs would not have any meaning on the 
remote end. Character UIDs can be translated into numeric UIDs between the two 
computers.

So my proposal is basically to add a fallback character username recognition to 
9p2000.u if numeric UID fails to be recognized. If Linux kernel always passes 
-1 for nuname, 9p2000.u would never work properly for kernel mounts.

I haven't checked the current kernel code, but at some point in the past, the 
kernel used to pass numeric uid to the user-space 9p server, you just need to 
make sure that your server supports the "nobody" (~0) uid too. Your server will 
get multiple Tattach messages, each for any uid that accesses files on the 
server.

So then 4294967295 in these messages is "inverted 32bit 0" however UID for 
nobody at least on this Ubuntu instance is 65534. Maybe mount options 
dfltuid/dfltgid will help, I'll check that. Would it make sense for Uid2User to 
resolve to "nobody" for any numeric UID that cannot be mapped to username on 
the current system?

The kernel doesn't have a way to know anything about what numerical value the 
"nobody" user has. For that reason the 9p filesystem uses ~0 to make sure 
anybody can attach to the server. In that sense, ~0 means more like "anybody", 
than "nobody". 

You can create your own implementations of the Users and Groups interfaces that 
do anything you would like. I'd rather keep osUsers and osGroups the way they 
are, because I am not sure if the changes won't break something else.

OK, thanks. Perhaps I understand it better now. I cannot change the status of 
the issue myself, but I think you can close it.