Closed GoogleCodeExporter closed 8 years ago
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.
Original comment by lion...@gmail.com
on 5 Dec 2014 at 6:04
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.
Original comment by golubov...@gmail.com
on 6 Dec 2014 at 4:59
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.
Original comment by lion...@gmail.com
on 6 Dec 2014 at 5:31
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?
Original comment by golubov...@gmail.com
on 6 Dec 2014 at 2:54
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.
Original comment by lion...@gmail.com
on 6 Dec 2014 at 3:10
OK, thanks. Perhaps I understand it better now. I cannot change the status of
the issue myself, but I think you can close it.
Original comment by golubov...@gmail.com
on 7 Dec 2014 at 2:07
Original comment by lion...@gmail.com
on 7 Dec 2014 at 8:18
Original issue reported on code.google.com by
golubov...@gmail.com
on 27 Sep 2014 at 1:56Attachments: