[9fans] v9fs question

[9fans] v9fs question

[Tim Newsham]

The documentation in the linux kernel says you merely

    mount -t 9p ipaddress /mntpoint

this fails on my system since /sbin/mount tries to execute /sbin/mount.9p
and fails.  Am I supposed to have an /sbin/mount.9p? (Anyone know which
ubunutu package should have this?  If not, where I might find sources?
Ironic since Ubuntu came with the 9p kernel module)  Or should I be using
a different mount program for the purpose?

The linux Documentation/filesystems/9p.txt should probably be updated with
more details, either way.

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] v9fs question

[Eric Van Hensbergen]

Hmmm, that's really new behavior-- never used to fail without mount
helper.  Can you give the exact error message?


Patches to documentation and/or code gladly accepted.
Sent from my iPhone

On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote:

> The documentation in the linux kernel says you merely
>
>   mount -t 9p ipaddress /mntpoint
>
> this fails on my system since /sbin/mount tries to execute /sbin/
> mount.9p and fails.  Am I supposed to have an /sbin/mount.9p?
> (Anyone know which ubunutu package should have this?  If not, where
> I might find sources? Ironic since Ubuntu came with the 9p kernel
> module)  Or should I be using a different mount program for the
> purpose?
>
> The linux Documentation/filesystems/9p.txt should probably be
> updated with more details, either way.
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>

Re: [9fans] v9fs question

[Tim Newsham]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1145 bytes --]

On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
> Hmmm, that's really new behavior-- never used to fail without mount helper.
> Can you give the exact error message?

   # strace -o trace.txt mount -t 9p thenewsh.com /mnt
   mount: Protocol not supported

Trace.txt is attached with full details.

I've tried several variants, such as thenewsh.com:/path
with similar results.

> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote:
>
>> The documentation in the linux kernel says you merely
>>
>>  mount -t 9p ipaddress /mntpoint
>>
>> this fails on my system since /sbin/mount tries to execute /sbin/mount.9p
>> and fails.  Am I supposed to have an /sbin/mount.9p? (Anyone know which
>> ubunutu package should have this?  If not, where I might find sources?
>> Ironic since Ubuntu came with the 9p kernel module)  Or should I be using a
>> different mount program for the purpose?
>>
>> The linux Documentation/filesystems/9p.txt should probably be updated with
>> more details, either way.
>>
>> Tim Newsham
>> http://www.thenewsh.com/~newsham/
>>
>

Tim Newsham
http://www.thenewsh.com/~newsham/

[-- Attachment #2: Type: TEXT/plain, Size: 10506 bytes --]

execve("/bin/mount", ["mount", "-t", "9p", "thenewsh.com", "/mnt"], [/* 39 vars */]) = 0
brk(0)                                  = 0x805e000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7faf000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=53546, ...}) = 0
mmap2(NULL, 53546, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa1000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libselinux.so.1", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300@\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=95948, ...}) = 0
mmap2(NULL, 101180, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f88000
mmap2(0xb7f9f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16) = 0xb7f9f000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1364388, ...}) = 0
mmap2(NULL, 1369712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e39000
mmap2(0xb7f82000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149) = 0xb7f82000
mmap2(0xb7f85000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f85000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9684, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e38000
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e34000
mmap2(0xb7e36000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7e36000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e33000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e33720, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f82000, 4096, PROT_READ)   = 0
munmap(0xb7fa1000, 53546)               = 0
brk(0)                                  = 0x805e000
brk(0x807f000)                          = 0x807f000
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
statfs64("/selinux", 84, 0xbfea3dfc)    = -1 ENOENT (No such file or directory)
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fae000
read(3, "rootfs / rootfs rw 0 0\nnone /sys"..., 1024) = 1024
read(3, "p_id=1000 0 0\n", 1024)        = 14
read(3, "", 1024)                       = 0
close(3)                                = 0
munmap(0xb7fae000, 4096)                = 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2586, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fae000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2586
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0xb7fae000, 4096)                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=373, ...}) = 0
mmap2(NULL, 373, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fae000
close(3)                                = 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=25700, ...}) = 0
mmap2(NULL, 25700, PROT_READ, MAP_SHARED, 3, 0) = 0xb7fa7000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_MEASUREMENT", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_MEASUREMENT", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
mmap2(NULL, 23, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa6000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_TELEPHONE", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_TELEPHONE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0
mmap2(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa5000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_ADDRESS", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_ADDRESS", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=155, ...}) = 0
mmap2(NULL, 155, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa4000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_NAME", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_NAME", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=77, ...}) = 0
mmap2(NULL, 77, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa3000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_PAPER", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_PAPER", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=34, ...}) = 0
mmap2(NULL, 34, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa2000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3)                                = 0
open("/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=52, ...}) = 0
mmap2(NULL, 52, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa1000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_MONETARY", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_MONETARY", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=286, ...}) = 0
mmap2(NULL, 286, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7e32000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_COLLATE", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_COLLATE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=921214, ...}) = 0
mmap2(NULL, 921214, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d51000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_TIME", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_TIME", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2451, ...}) = 0
mmap2(NULL, 2451, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d50000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_NUMERIC", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_NUMERIC", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
mmap2(NULL, 54, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d4f000
close(3)                                = 0
open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=254076, ...}) = 0
mmap2(NULL, 254076, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d10000
close(3)                                = 0
umask(022)                              = 022
open("/dev/null", O_RDWR|O_LARGEFILE)   = 3
close(3)                                = 0
getuid32()                              = 0
geteuid32()                             = 0
lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=650, ...}) = 0
getcwd("/usr/src/linux-source-2.6.24", 4095) = 29
readlink("/usr/src/linux-source-2.6.24/thenewsh.com", 0xbfea2c17, 4096) = -1 ENOENT (No such file or directory)
stat64("/sbin/mount.9p", 0xbfea49c4)    = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
stat64("/sbin/mount.9p", 0xbfea4994)    = -1 ENOENT (No such file or directory)
mount("thenewsh.com", "/mnt", "9p", MS_MGC_VAL, NULL) = -1 EPROTONOSUPPORT (Protocol not supported)
rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "mount: Protocol not supported", 29) = 29
write(2, "\n", 1)                       = 1
exit_group(32)                          = ?

Re: [9fans] v9fs question

[Eric Van Hensbergen]

Try an ip address instead of the DNS name.  For the DNS name you'll
need a helper like 9mount.

Sent from my iPhone

On Jul 11, 2009, at 2:03 PM, Tim Newsham <newsham@lava.net> wrote:

> On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
>> Hmmm, that's really new behavior-- never used to fail without mount
>> helper. Can you give the exact error message?
>
>  # strace -o trace.txt mount -t 9p thenewsh.com /mnt
>  mount: Protocol not supported
>
> Trace.txt is attached with full details.
>
> I've tried several variants, such as thenewsh.com:/path
> with similar results.
>
>> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote:
>>
>>> The documentation in the linux kernel says you merely
>>>
>>> mount -t 9p ipaddress /mntpoint
>>> this fails on my system since /sbin/mount tries to execute /sbin/
>>> mount.9p and fails.  Am I supposed to have an /sbin/mount.9p?
>>> (Anyone know which ubunutu package should have this?  If not,
>>> where I might find sources? Ironic since Ubuntu came with the 9p
>>> kernel module)  Or should I be using a different mount program for
>>> the purpose?
>>> The linux Documentation/filesystems/9p.txt should probably be
>>> updated with more details, either way.
>>> Tim Newsham
>>> http://www.thenewsh.com/~newsham/
>>
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
> <trace.txt>

Re: [9fans] v9fs question

[J.R. Mauro]

On Sat, Jul 11, 2009 at 3:03 PM, Tim Newsham<newsham@lava.net> wrote:
> On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
>>
>> Hmmm, that's really new behavior-- never used to fail without mount
>> helper. Can you give the exact error message?
>
>  # strace -o trace.txt mount -t 9p thenewsh.com /mnt

Linux doesn't do resolution for you, you have to give raw ip
addresses. Maybe not the problem, but worth pointing out.

>  mount: Protocol not supported
>
> Trace.txt is attached with full details.
>
> I've tried several variants, such as thenewsh.com:/path
> with similar results.
>
>> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote:
>>
>>> The documentation in the linux kernel says you merely
>>>
>>>  mount -t 9p ipaddress /mntpoint
>>>
>>> this fails on my system since /sbin/mount tries to execute /sbin/mount.9p
>>> and fails.  Am I supposed to have an /sbin/mount.9p? (Anyone know which
>>> ubunutu package should have this?  If not, where I might find sources?
>>> Ironic since Ubuntu came with the 9p kernel module)  Or should I be using a
>>> different mount program for the purpose?
>>>
>>> The linux Documentation/filesystems/9p.txt should probably be updated
>>> with more details, either way.
>>>
>>> Tim Newsham
>>> http://www.thenewsh.com/~newsham/
>>>
>>
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/

Re: [9fans] v9fs question

[Uriel]

Using sqweek's 9mount is strongly recommended if you are using v9fs,
not only it deals with the silly and deficient linux mount command
(which somebody should submit a patch for some day I guess if we want
to be taken seriously as an nfs replacement), but it also hides the
ever changing v9fs mount flags under a more consistent and clear
interface.

The ability to mount and unmount 9p file servers without being root is
just a great extra.

http://sqweek.dnsdojo.org/code/9mount/

uriel

P.S.: Oh, and I think debian even packages 9mount!

On Sat, Jul 11, 2009 at 10:03 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
> On Sat, Jul 11, 2009 at 3:03 PM, Tim Newsham<newsham@lava.net> wrote:
>> On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
>>>
>>> Hmmm, that's really new behavior-- never used to fail without mount
>>> helper. Can you give the exact error message?
>>
>>  # strace -o trace.txt mount -t 9p thenewsh.com /mnt
>
> Linux doesn't do resolution for you, you have to give raw ip
> addresses. Maybe not the problem, but worth pointing out.
>
>>  mount: Protocol not supported
>>
>> Trace.txt is attached with full details.
>>
>> I've tried several variants, such as thenewsh.com:/path
>> with similar results.
>>
>>> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote:
>>>
>>>> The documentation in the linux kernel says you merely
>>>>
>>>>  mount -t 9p ipaddress /mntpoint
>>>>
>>>> this fails on my system since /sbin/mount tries to execute /sbin/mount.9p
>>>> and fails.  Am I supposed to have an /sbin/mount.9p? (Anyone know which
>>>> ubunutu package should have this?  If not, where I might find sources?
>>>> Ironic since Ubuntu came with the 9p kernel module)  Or should I be using a
>>>> different mount program for the purpose?
>>>>
>>>> The linux Documentation/filesystems/9p.txt should probably be updated
>>>> with more details, either way.
>>>>
>>>> Tim Newsham
>>>> http://www.thenewsh.com/~newsham/
>>>>
>>>
>>
>> Tim Newsham
>> http://www.thenewsh.com/~newsham/
>
>

Re: [9fans] v9fs question

[sqweek]

 You'll notice it still tries mount(2) after stat(2) reveals that
mount.9p doesn't exist. mount(8) always looks for a helper and will
call it if it exists, but it doesn't fail when no helper is present.
 As others have said, mount(2) doesn't do name resolution, but by my
reading that should give you an "Invalid argument" error instead of
"Protocol not supported". However the only place I see EPROTONOSUPPORT
looks like an impossible code path... unless you have CONFIG_9P_FS
enabled in your kernel but not CONFIG_NET_9P... which also shouldn't
be possible with a current kernel. What version are you running?
 Anyway, note that if you auth you'll need supporting software from
p9p also. Factotum and srv -a, in particular, then give v9fs a -o
trans=unix.

 Oh, and to preempt the question why 9mount is not packaged as
mount.9p - mount(8) requires that you are root or your mount target is
in fstab with '-o user' before calling the helper, defeating the
purpose of an SUID mount.9p.
-sqweek


2009/7/12 Tim Newsham <newsham@lava.net>:
> On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
>>
>> Hmmm, that's really new behavior-- never used to fail without mount
>> helper. Can you give the exact error message?
>
>  # strace -o trace.txt mount -t 9p thenewsh.com /mnt
>  mount: Protocol not supported
>
> Trace.txt is attached with full details.
>
> I've tried several variants, such as thenewsh.com:/path
> with similar results.
>
>> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote:
>>
>>> The documentation in the linux kernel says you merely
>>>
>>>  mount -t 9p ipaddress /mntpoint
>>>
>>> this fails on my system since /sbin/mount tries to execute /sbin/mount.9p
>>> and fails.  Am I supposed to have an /sbin/mount.9p? (Anyone know which
>>> ubunutu package should have this?  If not, where I might find sources?
>>> Ironic since Ubuntu came with the 9p kernel module)  Or should I be using a
>>> different mount program for the purpose?
>>>
>>> The linux Documentation/filesystems/9p.txt should probably be updated
>>> with more details, either way.

Re: [9fans] v9fs question

[hiro]

>  mount: Protocol not supported

There was a time where you had to modprobe 9p2000 first. Should be worth a try.

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Mon, Jul 13, 2009 at 3:24 AM, sqweek<sqweek@gmail.com> wrote:
>  Anyway, note that if you auth you'll need supporting software from
> p9p also. Factotum and srv -a, in particular, then give v9fs a -o
> trans=unix.
>

Any chance we can get fossil integration into 9mount directly?  Most of
the code is already available in some p9p code that lucho wrote called
amount.  It would complicate build a bit because you need libraries from
p9p, but perhaps it could be conditional compilation.

>  Oh, and to preempt the question why 9mount is not packaged as
> mount.9p - mount(8) requires that you are root or your mount target is
> in fstab with '-o user' before calling the helper, defeating the
> purpose of an SUID mount.9p.

Well, IMHO it would be nice to have it named (or symlinked as) mount.9p
folks who mount as root could get the helper automatically.  This
would be nice for the standard Linux admin who is mounting crap as
root anyways and trips over the DNS resolution error because all
they are used to is NFS which mount has always done DNS for.

            -eric

Re: [9fans] v9fs question

[hiro]

> Well, IMHO it would be nice to have it named (or symlinked as) mount.9p
> folks who mount as root could get the helper automatically.  This
> would be nice for the standard Linux admin who is mounting crap as
> root anyways and trips over the DNS resolution error because all
> they are used to is NFS which mount has always done DNS for.

If they invest their time to find out about the mount.9p command,
won't they rather easily understand the DNS issue?

Re: [9fans] v9fs question

[hiro]

When I need remote access I nowadays use v9fs+ssh.
Multi-user auth in kernel like you propose sounds nice and consistent,
but too complicated. It doesn't fit linux, and thus an additional
deamon would mean one more place of security relevant code prone to
bugs. And even if this is only intended to be used locally I don't
think it would be good enough for our distributed operating system's
main network protocol.
>From a security (and perhaps simplicity) point of view userspace
authentication sounds more reasonable to me, p9p together with
something like fuse (even together with the new userspace hackery) or
perhaps a single-user v9fs combined with inferno for doing the
auth/crypt work seems a lot more reasonable to me than additional
clever hackery from the plan9 side. Not sure if somebody has something
like this working already...

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Mon, Jul 13, 2009 at 4:45 PM, hiro<23hiro@googlemail.com> wrote:
> When I need remote access I nowadays use v9fs+ssh.
> Multi-user auth in kernel like you propose sounds nice and consistent,
> but too complicated. It doesn't fit linux, and thus an additional
> deamon would mean one more place of security relevant code prone to
> bugs.
>

While I agree with that being the state of things today, it doesn't mean
we shouldn't push for better.  Maybe the Glendix folks will make things
consistent (and bug free).

>
> From a security (and perhaps simplicity) point of view userspace
> authentication sounds more reasonable to me, p9p together with
> something like fuse (even together with the new userspace hackery) or
> perhaps a single-user v9fs combined with inferno for doing the
> auth/crypt work seems a lot more reasonable to me than additional
> clever hackery from the plan9 side. Not sure if somebody has something
> like this working already...
>

I have a variant using Inferno right now, mounting the file system directly
from the stdin/stdout of the emu.  Combined with private namespaces it
provides a seemingly secure mechanism for accessing remote resources
as well as providing local resources to remote cpu services.

       -eric

Re: [9fans] v9fs question

[J.R. Mauro]

On Mon, Jul 13, 2009 at 6:05 PM, Eric Van Hensbergen<ericvh@gmail.com> wrote:
> On Mon, Jul 13, 2009 at 4:45 PM, hiro<23hiro@googlemail.com> wrote:
>> When I need remote access I nowadays use v9fs+ssh.
>> Multi-user auth in kernel like you propose sounds nice and consistent,
>> but too complicated. It doesn't fit linux, and thus an additional
>> deamon would mean one more place of security relevant code prone to
>> bugs.
>>
>
> While I agree with that being the state of things today, it doesn't mean
> we shouldn't push for better.  Maybe the Glendix folks will make things
> consistent (and bug free).

We hope to. One of the reasons it would actually be unwise to let
anyone mount anything now is that no one uses per-process namespaces.
That's probably fine on your desktop, but not on a server where 20
people try to mount something under /mnt/foo or whatnot.

On the security side, I helped get the plan9-style authentication
device in the mainline kernel. It's in staging. I guess the PAM module
is 90% done, but they need some help if anyone is interested.

>
>>
>> From a security (and perhaps simplicity) point of view userspace
>> authentication sounds more reasonable to me, p9p together with
>> something like fuse (even together with the new userspace hackery) or
>> perhaps a single-user v9fs combined with inferno for doing the
>> auth/crypt work seems a lot more reasonable to me than additional
>> clever hackery from the plan9 side. Not sure if somebody has something
>> like this working already...
>>
>
> I have a variant using Inferno right now, mounting the file system directly
> from the stdin/stdout of the emu.  Combined with private namespaces it
> provides a seemingly secure mechanism for accessing remote resources
> as well as providing local resources to remote cpu services.
>
>       -eric
>
>

Re: [9fans] v9fs question

[ron minnich]

On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@gmail.com> wrote:

> We hope to. One of the reasons it would actually be unwise to let
> anyone mount anything now is that no one uses per-process namespaces.
> That's probably fine on your desktop, but not on a server where 20
> people try to mount something under /mnt/foo or whatnot.

Could we solve this by making private mounts the default (or only
allowed) behavior?

That's how I did it long ago: it took real effort to make a mount non-private.

ron

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Mon, Jul 13, 2009 at 6:16 PM, ron minnich<rminnich@gmail.com> wrote:
> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
>
>> We hope to. One of the reasons it would actually be unwise to let
>> anyone mount anything now is that no one uses per-process namespaces.
>> That's probably fine on your desktop, but not on a server where 20
>> people try to mount something under /mnt/foo or whatnot.
>
> Could we solve this by making private mounts the default (or only
> allowed) behavior?
>
> That's how I did it long ago: it took real effort to make a mount non-private.
>

Not sure how easy or difficult this would be inside the kernel -- the
central problem last time I looked at it was it was difficult to
unshare namespace after the fork.  Of course you could check to make
sure you were not in the global namespace and error -- that should be
easy enough.

       -eric

Re: [9fans] v9fs question

[ron minnich]

On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergen<ericvh@gmail.com> wrote:

> Not sure how easy or difficult this would be inside the kernel -- the
> central problem last time I looked at it was it was difficult to
> unshare namespace after the fork.

Well, my mount command cheated. When you ran the mount command, it did
a fork and set CLONE_NS. You were, at that point, in a private name
space. Yes, ugly, but it certainly ensured a private mount.


> Of course you could check to make
> sure you were not in the global namespace and error -- that should be
> easy enough.

That's a nice idea. You require users of the command to have a clean
name space, or at least a non-global one, before you mount. That seems
like a nice solution to the problem.

ron

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Mon, Jul 13, 2009 at 6:37 PM, ron minnich<rminnich@gmail.com> wrote:
> On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergen<ericvh@gmail.com> wrote:
>
>> Not sure how easy or difficult this would be inside the kernel -- the
>> central problem last time I looked at it was it was difficult to
>> unshare namespace after the fork.
>
> Well, my mount command cheated. When you ran the mount command, it did
> a fork and set CLONE_NS. You were, at that point, in a private name
> space. Yes, ugly, but it certainly ensured a private mount.
>

Sure, and 9mount could do the same thing, but it would be nice to
enforce it from the kernel somehow.

     -eric

Re: [9fans] v9fs question

[J.R. Mauro]

On Mon, Jul 13, 2009 at 7:16 PM, ron minnich<rminnich@gmail.com> wrote:
> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
>
>> We hope to. One of the reasons it would actually be unwise to let
>> anyone mount anything now is that no one uses per-process namespaces.
>> That's probably fine on your desktop, but not on a server where 20
>> people try to mount something under /mnt/foo or whatnot.
>
> Could we solve this by making private mounts the default (or only
> allowed) behavior?

It would be nice to fix up mounts so that you didn't need to be root
and all that crap, and then make it the default, but I doubt Linus
would let it fly. I get the feeling that private namespaces are viewed
like chroots: a security feature no one but pros needs. Unfortunately
not many linux devs seem to care about plan 9, and that has a negative
impact on how much stuff can happen. Hopefully we'll gradually wear
them down, or keep a minifork/patchset.

>
> That's how I did it long ago: it took real effort to make a mount non-private.
>
> ron
>
>

Re: [9fans] v9fs question

[erik quanstrom]

> It would be nice to fix up mounts so that you didn't need to be root
> and all that crap, and then make it the default, but I doubt Linus
> would let it fly. I get the feeling that private namespaces are viewed
> like chroots: a security feature no one but pros needs. Unfortunately
> not many linux devs seem to care about plan 9, and that has a negative
> impact on how much stuff can happen. Hopefully we'll gradually wear
> them down, or keep a minifork/patchset.

i think if the linux folks really appreciated what one
could do with namespaces, a number of the
container bolt-on things could be implemented in terms
of namespace.

(then again, i have a feeling the same could be said of
plan 9.)

it's quite interesting to see how taking the seemingly-
conservative approach at every turn can take you
much further from v7 than even pretty radical breaks
like plan 9.

- erik

Re: [9fans] v9fs question

[J.R. Mauro]

On Mon, Jul 13, 2009 at 7:50 PM, erik quanstrom<quanstro@quanstro.net> wrote:
>> It would be nice to fix up mounts so that you didn't need to be root
>> and all that crap, and then make it the default, but I doubt Linus
>> would let it fly. I get the feeling that private namespaces are viewed
>> like chroots: a security feature no one but pros needs. Unfortunately
>> not many linux devs seem to care about plan 9, and that has a negative
>> impact on how much stuff can happen. Hopefully we'll gradually wear
>> them down, or keep a minifork/patchset.
>
> i think if the linux folks really appreciated what one
> could do with namespaces, a number of the
> container bolt-on things could be implemented in terms
> of namespace.

So much cruft would go right out the window if only it were accessible.

>
> (then again, i have a feeling the same could be said of
> plan 9.)

Of course, everything has cruft. But Plan 9 is decent to imitate since
it is less crufty.

>
> it's quite interesting to see how taking the seemingly-
> conservative approach at every turn can take you
> much further from v7 than even pretty radical breaks
> like plan 9.
>
> - erik
>

Agreed.

Re: [9fans] v9fs question

[erik quanstrom]

> > (then again, i have a feeling the same could be said of
> > plan 9.)
>
> Of course, everything has cruft. But Plan 9 is decent to imitate since
> it is less crufty.

not only is plan 9 cleaner, it's core ideas are all high quality,
and one can understand it.  so when it comes time to add one's
own brand of cruft, it's easy to do.

unfortunately plan 9 does not make good ideas any easier
to come by.

- erik

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
> On Mon, Jul 13, 2009 at 7:16 PM, ron minnich<rminnich@gmail.com> wrote:
>> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
>>
>>> We hope to. One of the reasons it would actually be unwise to let
>>> anyone mount anything now is that no one uses per-process namespaces.
>>> That's probably fine on your desktop, but not on a server where 20
>>> people try to mount something under /mnt/foo or whatnot.
>>
>> Could we solve this by making private mounts the default (or only
>> allowed) behavior?
>
> It would be nice to fix up mounts so that you didn't need to be root
> and all that crap, and then make it the default, but I doubt Linus
> would let it fly. I get the feeling that private namespaces are viewed
> like chroots: a security feature no one but pros needs. Unfortunately
> not many linux devs seem to care about plan 9, and that has a negative
> impact on how much stuff can happen. Hopefully we'll gradually wear
> them down, or keep a minifork/patchset.
>

When things get further along we can do a coordinated assault :)
We've got bits of mindshare spread out over different places including
a couple of the major distributions, if things can be made optional
they'll make it into mainline and then we just need to focus on
education by presenting demos at places like OLS, Plumbers, and LCA --
and maybe get some good video podcast tutorials up on YouTube to get
people wanting and using the features.  Of course the main thing is
finding a niche that needs the features and selling them on it.  The
focus on cloud computing and other cluster type solutions in
mainstream computing may be helpful there.

        -eric

Re: [9fans] v9fs question

[ron minnich]

you need to find the niche and provide programs, which people can just
use. Or you need to find the niche that lets other people write
programs, and we're not where we need to be on that score. It's still
too hard for people to write servers and there's no clear answer on
which library to use. FUSE has done a great job in this area.

ron

Re: [9fans] v9fs question

[J.R. Mauro]

On Mon, Jul 13, 2009 at 8:08 PM, ron minnich<rminnich@gmail.com> wrote:
> you need to find the niche and provide programs, which people can just
> use. Or you need to find the niche that lets other people write
> programs, and we're not where we need to be on that score. It's still
> too hard for people to write servers and there's no clear answer on
> which library to use. FUSE has done a great job in this area.
>
> ron
>
>

Unfortunately, the only niches being filled are by other 9fans :P

We've got some cool stuff by sqweek and Kris Maglione that are
linux-specific, but the world at large is mostly ignorant of it. I'm
sure adding things like /net will turn the tide.

Re: [9fans] v9fs question

[J.R. Mauro]

On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergen<ericvh@gmail.com> wrote:
> On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
>> On Mon, Jul 13, 2009 at 7:16 PM, ron minnich<rminnich@gmail.com> wrote:
>>> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
>>>
>>>> We hope to. One of the reasons it would actually be unwise to let
>>>> anyone mount anything now is that no one uses per-process namespaces.
>>>> That's probably fine on your desktop, but not on a server where 20
>>>> people try to mount something under /mnt/foo or whatnot.
>>>
>>> Could we solve this by making private mounts the default (or only
>>> allowed) behavior?
>>
>> It would be nice to fix up mounts so that you didn't need to be root
>> and all that crap, and then make it the default, but I doubt Linus
>> would let it fly. I get the feeling that private namespaces are viewed
>> like chroots: a security feature no one but pros needs. Unfortunately
>> not many linux devs seem to care about plan 9, and that has a negative
>> impact on how much stuff can happen. Hopefully we'll gradually wear
>> them down, or keep a minifork/patchset.
>>
>
> When things get further along we can do a coordinated assault :)

Indeed :)

> We've got bits of mindshare spread out over different places including
> a couple of the major distributions, if things can be made optional

We've got Greg KH and Christoph on our side. I'm sure viro would also
be a voice in our favor, and he has some pull with Linus

> they'll make it into mainline and then we just need to focus on
> education by presenting demos at places like OLS, Plumbers, and LCA --
> and maybe get some good video podcast tutorials up on YouTube to get
> people wanting and using the features.  Of course the main thing is
> finding a niche that needs the features and selling them on it.  The
> focus on cloud computing and other cluster type solutions in
> mainstream computing may be helpful there.

Yes, showing people the benefits of /net and how simple clustering is
will be the path to victory. People will be amazed when they see how
easy it is to make 5 computers pretend to be one.

>
>        -eric
>
>

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Mon, Jul 13, 2009 at 7:42 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
> On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergen<ericvh@gmail.com> wrote:
>> On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
>>> On Mon, Jul 13, 2009 at 7:16 PM, ron minnich<rminnich@gmail.com> wrote:
>>>> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@gmail.com> wrote:
>> they'll make it into mainline and then we just need to focus on
>> education by presenting demos at places like OLS, Plumbers, and LCA --
>> and maybe get some good video podcast tutorials up on YouTube to get
>> people wanting and using the features.  Of course the main thing is
>> finding a niche that needs the features and selling them on it.  The
>> focus on cloud computing and other cluster type solutions in
>> mainstream computing may be helpful there.
>
> Yes, showing people the benefits of /net and how simple clustering is
> will be the path to victory. People will be amazed when they see how
> easy it is to make 5 computers pretend to be one.
>

I can validate this to some extent.  The ability to transitively mount
/net was one of the most popular features of the Library OS
environment I worked on a few years back.  It was really easy for
Linux and UNIX minded folks to grasp how powerful it was:
         http://portal.acm.org/citation.cfm?id=1254810.1254817

       -eric

[9fans] v9fs question

[Latchesar Ionkov]

I don't see why should we do tricks like that. We have support for
private namespaces, why should we make the linux code even more
complicated?

Thanks,
    Lucho

On Monday, July 13, 2009, Tim Newsham <newsham@lava.net> wrote:
>
> Could we solve this by making private mounts the default (or only
> allowed) behavior?
>
>
> I've wondered if there's enough context information
> that the fs driver could "fake" per-process mount points
> directly.  For example, I mount v9fs on /n.  Initially
> I have no remote mounts in there, but I have /n/ctl.
> I echo "mount 1.2.3.4 foo" to /n/ctl and now I have
> /n/foo which is served from 1.2.3.4 for my process, but
> other processes dont see /n/foo.  I fork a child and it
> gets /n/foo, too.  In the child I mount another directory
> and the changes are seen in both the child and the parent.
> I then echo "copyns" to /n/ctl and then perform another
> mount and the new mount is visible in the child process but
> not the parent process.
>
> This would of course require that the kernel filesystem
> (probably vfs layer) could distinguish who made a filesystem
> request.  It might also require some hackery to get the
> inheritance on fork working properly (although perhaps some
> existing unix mechanism could be reused for this purpose, such
> as session and process group stuff).
>
> Feasible at all in Linux? *BSD?  Win32?
>
> Upsides: Kernel doesnt need to otherwise support any notion
> of mount namespace.  Removes security concerns of per-process
> namespaces since you could never rebind over /etc/passwd or
> other important files.
>
> Downsides: Perhaps not possible.  Mount/bind namespaces not
> universally present, only within certain mount points.
>
>
> ron
>
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>
>

Re: [9fans] v9fs question

[Devon H. O'Dell]

I believe Priyanka has some significant work on getting private
per-process namespaces in Glendix for this year's GSoC.

--dho

Re: [9fans] v9fs question

[Tim Newsham]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 462 bytes --]

> I don't see why should we do tricks like that. We have support for
> private namespaces, why should we make the linux code even more
> complicated?

Some of us use systems other than Linux.  Also, it may be
easier to sell one idea (v9fs) than two ideas (v9fs +
private name spaces).  It seems that people who have used
UNIX for a long time have a natural aversion to the latter.

> Thanks,
>    Lucho

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] v9fs question

[Tim Newsham]

> Could we solve this by making private mounts the default (or only
> allowed) behavior?

I've wondered if there's enough context information
that the fs driver could "fake" per-process mount points
directly.  For example, I mount v9fs on /n.  Initially
I have no remote mounts in there, but I have /n/ctl.
I echo "mount 1.2.3.4 foo" to /n/ctl and now I have
/n/foo which is served from 1.2.3.4 for my process, but
other processes dont see /n/foo.  I fork a child and it
gets /n/foo, too.  In the child I mount another directory
and the changes are seen in both the child and the parent.
I then echo "copyns" to /n/ctl and then perform another
mount and the new mount is visible in the child process but
not the parent process.

This would of course require that the kernel filesystem
(probably vfs layer) could distinguish who made a filesystem
request.  It might also require some hackery to get the
inheritance on fork working properly (although perhaps some
existing unix mechanism could be reused for this purpose, such
as session and process group stuff).

Feasible at all in Linux? *BSD?  Win32?

Upsides: Kernel doesnt need to otherwise support any notion
of mount namespace.  Removes security concerns of per-process
namespaces since you could never rebind over /etc/passwd or
other important files.

Downsides: Perhaps not possible.  Mount/bind namespaces not
universally present, only within certain mount points.

> ron

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] v9fs question

[erik quanstrom]

On Mon Jul 13 20:43:21 EDT 2009, newsham@lava.net wrote:
> > Could we solve this by making private mounts the default (or only
> > allowed) behavior?
>
> I've wondered if there's enough context information
> that the fs driver could "fake" per-process mount points
> directly.  For example, I mount v9fs on /n.  Initially
> I have no remote mounts in there, but I have /n/ctl.
> I echo "mount 1.2.3.4 foo" to /n/ctl and now I have
> /n/foo which is served from 1.2.3.4 for my process, but
> other processes dont see /n/foo.  I fork a child and it
> gets /n/foo, too.  In the child I mount another directory
> and the changes are seen in both the child and the parent.
> I then echo "copyns" to /n/ctl and then perform another
> mount and the new mount is visible in the child process but
> not the parent process.

i believe you've described the speaks-for relationship
in plan 9.

>
> This would of course require that the [linux] kernel filesystem
> (probably vfs layer) could distinguish who made a filesystem
> request.  It might also require some hackery to get the
> inheritance on fork working properly (although perhaps some
> existing unix mechanism could be reused for this purpose, such
> as session and process group stuff).

how could the fs record the creat without having the uid/gid?

- erik

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Mon, Jul 13, 2009 at 7:42 PM, Tim Newsham<newsham@lava.net> wrote:
>> Could we solve this by making private mounts the default (or only
>> allowed) behavior?
>
> I've wondered if there's enough context information
> that the fs driver could "fake" per-process mount points
> directly.
>

Lucho's v9fs auth mechanisms allow for per-user namespaces (sort-of)
as they force a new-attach ever time a new user crosses the mount
point.  I think there's enough knowledge (in Linux anyways) to obtain
the current process.  The hard bit is, as you say, managing
inheritance and other namespace process controls.  This is why its
probably best implemented in a more integrated fashion.

I have been playing with using Inferno to construct dynamic namespaces
for me in Linux and MacOSX.  The idea is to setup the namespace and
then back mount it (with v9fs and FUSE) in either a private namespace
or a chroot.  I'm using this to implement an xcpu2-like environment
purely with Inferno (remote threads get their own private namespace
sandboxes to run in with an Inferno crafted namespace).  Not as
powerful as the whole enchilada, but it provides a container
environment with composable namespaces.

       -eric

Re: [9fans] v9fs question

[lucio]

> I've wondered if there's enough context information
> that the fs driver could "fake" per-process mount points
> directly.

A totally uneducated shot in the dark: would having a userspace
"mount" command that creates a private namespace (vaguely what you
describe in your note) not be a good starting point?  I'd use /ns
rather than /n as the root, but that's really a small thing.

Unfortunately, I have no idea (yet) of the machinery provided by Linux
to construct private namespaces.  And I am not aware of any equivalent
work in the NetBSD world.

++L

Re: [9fans] v9fs question

[lucio]

> On the security side, I helped get the plan9-style authentication
> device in the mainline kernel. It's in staging. I guess the PAM module
> is 90% done, but they need some help if anyone is interested.

Where do I look for this?  I don't know Linux or PAM well enough to
believe I can help, but one never knows.

++L

Re: [9fans] v9fs question

[lucio]

> I have a variant using Inferno right now, mounting the file system directly
> from the stdin/stdout of the emu.

This isn't very practical in my case, because I need to port emu
to the Yeeloong first.  Hiro suggested using "v9fs+ssh", I'd be
interested in that option as a stopgap, but again some directions
would be helpful.

++L

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Mon, Jul 13, 2009 at 3:44 PM, hiro<23hiro@googlemail.com> wrote:
>> Well, IMHO it would be nice to have it named (or symlinked as) mount.9p
>> folks who mount as root could get the helper automatically.  This
>> would be nice for the standard Linux admin who is mounting crap as
>> root anyways and trips over the DNS resolution error because all
>> they are used to is NFS which mount has always done DNS for.
>
> If they invest their time to find out about the mount.9p command,
> won't they rather easily understand the DNS issue?
>

Well, if someone installs the mount.9p package, then it "just works"
-- at least at the same level of "just works" as CIFS and the other
second-class distributed file systems for Linux.  Its easier to tell
someone to install a package than step them through installing and
using a different command for mount than mount.

      -eric

Re: [9fans] v9fs question

[sqweek]

2009/7/13 Eric Van Hensbergen <ericvh@gmail.com>:
> On Mon, Jul 13, 2009 at 3:24 AM, sqweek<sqweek@gmail.com> wrote:
>>  Anyway, note that if you auth you'll need supporting software from
>> p9p also. Factotum and srv -a, in particular, then give v9fs a -o
>> trans=unix.
>
> Any chance we can get fossil integration into 9mount directly?  Most of
> the code is already available in some p9p code that lucho wrote called
> amount.  It would complicate build a bit because you need libraries from
> p9p, but perhaps it could be conditional compilation.

 I'm not too fond of the idea... It's not as though amount adds any
new functionality over srv+mount[1], and I hate throwing more code at
a problem when equivalent code exists elsewhere. Having to introduce a
link time dependency on p9p doesn't help convince me either - the
current arrangement seems to provide a decent seperation of
responsibility.
 The mount.9p symlink sounds pretty reasonable though, I'll get around
to that sometime.

[1] actually back when I read over amount I even concluded that it
used the same trick as srv -a just with a pipe instead of unix socket!
failed to notice the Tversion/Tattach subtlety. is it really worth the
coupling to go back to that approach?

-sqweek

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Tue, Jul 14, 2009 at 2:05 PM, sqweek<sqweek@gmail.com> wrote:
>
>  I'm not too fond of the idea... It's not as though amount adds any
> new functionality over srv+mount[1], and I hate throwing more code at
> a problem when equivalent code exists elsewhere. Having to introduce a
> link time dependency on p9p doesn't help convince me either - the
> current arrangement seems to provide a decent seperation of
> responsibility.
>  The mount.9p symlink sounds pretty reasonable though, I'll get around
> to that sometime.
>
> [1] actually back when I read over amount I even concluded that it
> used the same trick as srv -a just with a pipe instead of unix socket!
> failed to notice the Tversion/Tattach subtlety. is it really worth the
> coupling to go back to that approach?
>

Its not exactly the same.  amount didn't use a pipe, it started the
connection with an fd, did the auth and then passes the fd to the
kernel to use.  The use of the pipe adds extra copies on all data
after authentication.  This is the overhead involved with the srv
approach that I mentioned.  IMHO it is worth it for the performance.
There's also the security implications of the srv approach, but I was
never really much concerned with that angle.

        -eric

Re: [9fans] v9fs question

[lucio]

>  Anyway, note that if you auth you'll need supporting software from
> p9p also. Factotum and srv -a, in particular, then give v9fs a -o
> trans=unix.

Would you mind documenting this a little more explicitly and posting
it somewhere handy?  I'm sure you've given enough hints here to make
it work, but I can see that I have a merry documentation chase ahead
of me :-)

++L

Re: [9fans] v9fs question

[Eric Van Hensbergen]

If someone pulls together a verified HOWTO for the auth case,  I'd be
happy to add it to the Documentation/filesystems/9p.txt

     -eric

On Mon, Jul 13, 2009 at 9:59 AM, <lucio@proxima.alt.za> wrote:
>>  Anyway, note that if you auth you'll need supporting software from
>> p9p also. Factotum and srv -a, in particular, then give v9fs a -o
>> trans=unix.
>
> Would you mind documenting this a little more explicitly and posting
> it somewhere handy?  I'm sure you've given enough hints here to make
> it work, but I can see that I have a merry documentation chase ahead
> of me :-)
>
> ++L
>
>
>

Re: [9fans] v9fs question

[Latchesar Ionkov]

On Mon, Jul 13, 2009 at 2:24 AM, sqweek<sqweek@gmail.com> wrote:
>  Anyway, note that if you auth you'll need supporting software from
> p9p also. Factotum and srv -a, in particular, then give v9fs a -o
> trans=unix.

I don't think that auth is working with v9fs at all. The auth support
got dropped accidentally with some of the changes, probably when
access=user|any|<uid> was introduced. I.e. my fault.

Adding the support we had before the access= support is probably easy,
but I would like to make it better and support authentication for
multiple users. Still no idea what is the correct way. :( Any
suggestions are welcome.

Thanks,
    Lucho

Re: [9fans] v9fs question

[Tim Newsham]

> Adding the support we had before the access= support is probably easy,
> but I would like to make it better and support authentication for
> multiple users. Still no idea what is the correct way. :( Any
> suggestions are welcome.

I'm glad you brought this up because this is a conversation I wanted
to see.  I can think of several different ways to go about
this:


    - nfs style: if you authenticate to the remote as root,
      you can speak for any of the uids you want to.  This
      assumes a common mapping of users to uids across
      the machines.
      twist: root squash as an option, as per nfs.

   - single user:  All files are presented as if owned by
     a single user.  This need not be the user that was
     authenticated on the remote side.  Any local user id
     would work.  Perm checks are going to be done twice,
     anyway.  Once locally (based on perms + the user id
     assigned to all files) and once remotely (on file server)
     based on the remote's idea of what user id you are (who
     you authenticated as).

   - multi-user authentication:  A separate authenticated 9p
     channel is opened for each user that makes a request over
     the remote mount.  This requires that some daemon have
     access to credentials to authenticate each user at least
     once.  This daemon could be set up in advance or it could
     interactively request auth info as it goes.  I think
     one obvious approach is to prime it with creds for a bunch
     of accounts and have it fall back to the "single user"
     case for all other accounts -- by mapping to some distinguished
     user such as "nobody" or "guest" or "unauth9p".

by the way, I think auth method offers some room for thought
here, too.  When talking with plan9 or inferno then p9sk1
or the inferno auth (whose name I forget) is the obvious choice.
However, when talking just between several non-plan9 machines
(ie. linux-linux) then other auth choices might make sense.
How many 9p servers actually use auth?  Most "file servers"
are only accessed remotely through "cpu" or locally without
auth, right?

>    Lucho

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] v9fs question

[sqweek]

2009/7/13 Latchesar Ionkov <lucho@ionkov.net>:
> On Mon, Jul 13, 2009 at 2:24 AM, sqweek<sqweek@gmail.com> wrote:
>>  Anyway, note that if you auth you'll need supporting software from
>> p9p also. Factotum and srv -a, in particular, then give v9fs a -o
>> trans=unix.
>
> I don't think that auth is working with v9fs at all. The auth support
> got dropped accidentally with some of the changes, probably when
> access=user|any|<uid> was introduced. I.e. my fault.

 I didn't realise v9fs ever had auth support. Here is how I've been
getting an authenticated mount for years:

# create mountpoint
$ n=$HOME/n
$ mkdir -p $n/wren

# need factotum running to do the dirty work
$ factotum

# srv -a posts a pre-authenticated socket in the p9p ns directory
# wren is my fileserver
$ srv -a wren
!adding key: role=client proto=p9sk1 dom=sqweek.dnsdojo.org
user[sqweek]:
password:

$ 9mount -i 'unix!/tmp/ns.sqweek.:0/wren' $n/wren
 (or)
$ mount -t 9p -o uname=sqweek,trans=unix,noextend,dfltuid=$(id
-u),dfltgid=$(id -g) /tmp/ns.sqweek.:0/wren $n/wren
# I'm not sure if uname is strictly necessary

$ 9bind $n/wren/home/sqweek/mail $HOME/sqweek/mail
# various other binds

 Jorden mentioned it's a bad idea to let anyone mount anything because
everyone shares the same namespace. 9mount does have some sanity
checks for that environment, it will only let you mount over a
directory you have write access to (and isn't sticky) or is under your
home dir. Never really been field tested though :)

> Adding the support we had before the access= support is probably easy,
> but I would like to make it better and support authentication for
> multiple users. Still no idea what is the correct way. :( Any
> suggestions are welcome.

 Can't help you there - I'm not sure it makes sense to try and put
factotum's functionality in the linux kernel... Is there some problem
with the private namespace/individual user mount approach?
-sqweek

Re: [9fans] v9fs question

[roger peppe]

this is at a bit of a tangent from the previous discussion,
but something i've always wondered:

why does the linux 9p mount syscall bother
with IP addresses at all? isn't it sufficient
just to provide a facility for mounting a file descriptor
(like the plan 9 syscall) and have an auxiliary
command do the actual dial, authentication, etc?

wouldn't that be simpler and just as versatile?

Re: [9fans] v9fs question

[hiro]

On Tue, Jul 14, 2009 at 1:08 PM, roger peppe<rogpeppe@gmail.com> wrote:
> this is at a bit of a tangent from the previous discussion,
> but something i've always wondered:
>
> why does the linux 9p mount syscall bother
> with IP addresses at all? isn't it sufficient
> just to provide a facility for mounting a file descriptor
> (like the plan 9 syscall) and have an auxiliary
> command do the actual dial, authentication, etc?
>
> wouldn't that be simpler and just as versatile?
>
>

I perfectly agree.

And I used to think this was how FUSE is working, but this has been
only an uneducated guess.

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Jul 14, 2009, at 6:08 AM, roger peppe <rogpeppe@gmail.com> wrote:

> this is at a bit of a tangent from the previous discussion,
> but something i've always wondered:
>
> why does the linux 9p mount syscall bother
> with IP addresses at all? isn't it sufficient
> just to provide a facility for mounting a file descriptor
> (like the plan 9 syscall) and have an auxiliary
> command do the actual dial, authentication, etc?
>

This has always been an option.  The tcp transport is there (and is
default) because it is closest to the expected behavior for the naive
Linux user.  It is also there because at one time we used 9p as root
(ala nfsroot direct option in the kernel).

It's worth noting there are performance/efficency implications for
using the fd transport (particularly for the non-socket fd case like
sshsrv) as well as the unix named pipes transport -- but I don't have
quantitative analysis of the differences as it's hard to get an apples
to apples comparison.   Anthony ligouri has shown some really
promising numbers for a hybrid transport based on the Linux splice
command.

> wouldn't that be simpler

The code in question is mostly common, maybe 20 lines of code for each
tcp and unix, so I think it's worth having them as options so that
user space mount tools arent required.

Re: [9fans] v9fs question

[ron minnich]

On Tue, Jul 14, 2009 at 4:08 AM, roger peppe<rogpeppe@gmail.com> wrote:

> why does the linux 9p mount syscall bother
> with IP addresses at all? isn't it sufficient
> just to provide a facility for mounting a file descriptor
> (like the plan 9 syscall) and have an auxiliary
> command do the actual dial, authentication, etc?

The fd stuff has been in there in one form or another for 10 years. Just FYI.

ron

Re: [9fans] v9fs question

[Tim Newsham]

> this is at a bit of a tangent from the previous discussion,
> but something i've always wondered:
>
> why does the linux 9p mount syscall bother
> with IP addresses at all? isn't it sufficient
> just to provide a facility for mounting a file descriptor
> (like the plan 9 syscall) and have an auxiliary
> command do the actual dial, authentication, etc?
>
> wouldn't that be simpler and just as versatile?

The v9fs driver lets you mount from a file descriptor.
Is this what you're asking for?

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] v9fs question

[roger peppe]

2009/7/14 Tim Newsham <newsham@lava.net>:
> The v9fs driver lets you mount from a file descriptor.
> Is this what you're asking for?

i was aware it allowed a mount of a file descriptor.
in the interests of minimalism, i was wondering why
it did anything else.

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Jul 14, 2009, at 2:34 AM, sqweek <sqweek@gmail.com> wrote:

> 2009/7/13 Latchesar Ionkov <lucho@ionkov.net>:
>>
>
>> Adding the support we had before the access= support is probably
>> easy,
>> but I would like to make it better and support authentication for
>> multiple users. Still no idea what is the correct way. :( Any
>> suggestions are welcome.
>
> Can't help you there - I'm not sure it makes sense to try and put
> factotum's functionality in the linux kernel...

Probably don't need factotum in kernel, Linux has a keyring facility
that can be used to query userspace agents (like factotum).  We'd just
need the right hooks in v9fs and potentially a glue application to
match the kernel keyring API.

> Is there some problem
> with the private namespace/individual user mount approach?
>

Main annoyance is the lack of a proper srv device in Linux to
facilitate sharing already open connections.  This is t a problem for
per-user mounts --- but is a problem for private namespaces.  You can
use p9p srv as mentioned elsewhere in this thread, but then you incur
some additional overhead.

       -Eric

Re: [9fans] v9fs question

[erik quanstrom]

> Main annoyance is the lack of a proper srv device in Linux to
> facilitate sharing already open connections.  This is t a problem for
> per-user mounts --- but is a problem for private namespaces.  You can
> use p9p srv as mentioned elsewhere in this thread, but then you incur
> some additional overhead.

unless this is unmanagable slowness, wouldn't worring about
performance at this stage only stand in the way of getting
something working?

- erik

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Tue, Jul 14, 2009 at 8:23 AM, erik quanstrom<quanstro@quanstro.net> wrote:
>> Main annoyance is the lack of a proper srv device in Linux to
>> facilitate sharing already open connections.  This is t a problem for
>> per-user mounts --- but is a problem for private namespaces.  You can
>> use p9p srv as mentioned elsewhere in this thread, but then you incur
>> some additional overhead.
>
> unless this is unmanagable slowness, wouldn't worring about
> performance at this stage only stand in the way of getting
> something working?
>

Is something not working?  My understanding of the situation is that
many folks have a workable solution with p9p.  The issues are ones of
security, convenience and potentially performance.  I'm not really a
security expert, so I'll refrain from commenting on the first issue
outside of the fact that there are concerns with the use of setuid
applications, public mount points, and user-space managed connections
to file systems (the latter only being a concern if the file system in
question is the root partition).

Outside of security, the option of tighter auth integration (via the
keyring mechanism and fixing 9p.auth in v9fs) with the kernel module
is primarily a convenience issue with a side-dish of performance.

All that being said, I have no issues with the private mount approach,
and have advocated it both via a paper
(http://citeseer.ist.psu.edu/746023.html) and in the LKML mailing list
discussions on removing privilege restrictions from the Linux mount
system call.

         -eric

Re: [9fans] v9fs question

[erik quanstrom]

> Is something not working?

authentication?  or doesn't that count?

- erik

Re: [9fans] v9fs question

[Latchesar Ionkov]

Hmm, I don't understand how this works. v9fs should issue its own
Tversion and Tattach and discard the previously authenticated session,
right? Or I am missing something?

Thanks,
    Lucho

On Tue, Jul 14, 2009 at 1:34 AM, sqweek<sqweek@gmail.com> wrote:
> 2009/7/13 Latchesar Ionkov <lucho@ionkov.net>:
>> On Mon, Jul 13, 2009 at 2:24 AM, sqweek<sqweek@gmail.com> wrote:
>>>  Anyway, note that if you auth you'll need supporting software from
>>> p9p also. Factotum and srv -a, in particular, then give v9fs a -o
>>> trans=unix.
>>
>> I don't think that auth is working with v9fs at all. The auth support
>> got dropped accidentally with some of the changes, probably when
>> access=user|any|<uid> was introduced. I.e. my fault.
>
>  I didn't realise v9fs ever had auth support. Here is how I've been
> getting an authenticated mount for years:
>
> # create mountpoint
> $ n=$HOME/n
> $ mkdir -p $n/wren
>
> # need factotum running to do the dirty work
> $ factotum
>
> # srv -a posts a pre-authenticated socket in the p9p ns directory
> # wren is my fileserver
> $ srv -a wren
> !adding key: role=client proto=p9sk1 dom=sqweek.dnsdojo.org
> user[sqweek]:
> password:
>
> $ 9mount -i 'unix!/tmp/ns.sqweek.:0/wren' $n/wren
>  (or)
> $ mount -t 9p -o uname=sqweek,trans=unix,noextend,dfltuid=$(id
> -u),dfltgid=$(id -g) /tmp/ns.sqweek.:0/wren $n/wren
> # I'm not sure if uname is strictly necessary
>
> $ 9bind $n/wren/home/sqweek/mail $HOME/sqweek/mail
> # various other binds
>
>  Jorden mentioned it's a bad idea to let anyone mount anything because
> everyone shares the same namespace. 9mount does have some sanity
> checks for that environment, it will only let you mount over a
> directory you have write access to (and isn't sticky) or is under your
> home dir. Never really been field tested though :)
>
>> Adding the support we had before the access= support is probably easy,
>> but I would like to make it better and support authentication for
>> multiple users. Still no idea what is the correct way. :( Any
>> suggestions are welcome.
>
>  Can't help you there - I'm not sure it makes sense to try and put
> factotum's functionality in the linux kernel... Is there some problem
> with the private namespace/individual user mount approach?
> -sqweek
>
>

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Tue, Jul 14, 2009 at 9:33 AM, Latchesar Ionkov<lucho@ionkov.net> wrote:
> Hmm, I don't understand how this works. v9fs should issue its own
> Tversion and Tattach and discard the previously authenticated session,
> right? Or I am missing something?
>

It works because srv is serving its own (unauthenticated) version of
the mount via 9p.

I thought at one point in time we  had something in there that
bypassed tversion/tauth and that's how the amount stuff worked.  But I
don't see that code anymore, is that what got squashed with the new
auth= stuff?

    -eric

Re: [9fans] v9fs question

[erik quanstrom]

> I thought at one point in time we  had something in there that
> bypassed tversion/tauth and that's how the amount stuff worked.  But I
> don't see that code anymore, is that what got squashed with the new
> auth= stuff?

has anyone written anything to deal with an
exportfs connection on linux?

- erik

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Tue, Jul 14, 2009 at 10:01 AM, erik quanstrom<quanstro@coraid.com> wrote:
>> I thought at one point in time we  had something in there that
>> bypassed tversion/tauth and that's how the amount stuff worked.  But I
>> don't see that code anymore, is that what got squashed with the new
>> auth= stuff?
>
> has anyone written anything to deal with an
> exportfs connection on linux?
>

I'm confused about what you are asking.

     -eric

Re: [9fans] v9fs question

[erik quanstrom]

> > has anyone written anything to deal with an
> > exportfs connection on linux?
> >
>
> I'm confused about what you are asking.

if i have two plan 9 machines, i can
	import butts /mnt/consoles /n/consoles
however, since import and exportfs run a special
protocol in front of 9p, i don't think it's possible
to do the same thing from a linux host.

- erik

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Tue, Jul 14, 2009 at 10:19 AM, erik quanstrom<quanstro@coraid.com> wrote:
>> > has anyone written anything to deal with an
>> > exportfs connection on linux?
>> >
>>
>> I'm confused about what you are asking.
>
> if i have two plan 9 machines, i can
>        import butts /mnt/consoles /n/consoles
> however, since import and exportfs run a special
> protocol in front of 9p, i don't think it's possible
> to do the same thing from a linux host.
>

Yeah, I don't think anyone is currently doing anything like that.  I
think for a while we were using aname in one of the early 9P servers
to allow the mounting of a sub-hierarchy, but that's been gone for a
while I think and still wouldn't do the exact same thing you are
describing.

       -eric

Re: [9fans] v9fs question

[erik quanstrom]

> > if i have two plan 9 machines, i can
> >        import butts /mnt/consoles /n/consoles
> > however, since import and exportfs run a special
> > protocol in front of 9p, i don't think it's possible
> > to do the same thing from a linux host.
> >
>
> Yeah, I don't think anyone is currently doing anything like that.  I

i would, if it existed.  the current workarounds we
have are quite horrendous.

- erik

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Tue, Jul 14, 2009 at 11:12 AM, erik quanstrom<quanstro@coraid.com> wrote:
>> > if i have two plan 9 machines, i can
>> >        import butts /mnt/consoles /n/consoles
>> > however, since import and exportfs run a special
>> > protocol in front of 9p, i don't think it's possible
>> > to do the same thing from a linux host.
>> >
>>
>> Yeah, I don't think anyone is currently doing anything like that.  I
>
> i would, if it existed.  the current workarounds we
> have are quite horrendous.
>

patches gladly accepted :)

This is likely more of a wrapper application and server issue as you
point out of course rather than something which is implemented in the
kernel.

      -eric

Re: [9fans] v9fs question

[Latchesar Ionkov]

Yes, that's what was removed. When the code was still there, the
presence of the afid= option would prevent sending Tversion and would
use the specified afid on Tattach. It is not hard to put it back.

On Tue, Jul 14, 2009 at 8:54 AM, Eric Van Hensbergen<ericvh@gmail.com> wrote:
> I thought at one point in time we  had something in there that
> bypassed tversion/tauth and that's how the amount stuff worked.  But I
> don't see that code anymore, is that what got squashed with the new
> auth= stuff?

Re: [9fans] v9fs question

[ron minnich]

On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkov<lucho@ionkov.net> wrote:
> Yes, that's what was removed. When the code was still there, the
> presence of the afid= option would prevent sending Tversion and would
> use the specified afid on Tattach. It is not hard to put it back.

That sounds nice to me, I would love to see it back. Was there a
problem with it?

ron

Re: [9fans] v9fs question

[Eric Van Hensbergen]

On Tue, Jul 14, 2009 at 10:48 AM, ron minnich<rminnich@gmail.com> wrote:
> On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkov<lucho@ionkov.net> wrote:
>> Yes, that's what was removed. When the code was still there, the
>> presence of the afid= option would prevent sending Tversion and would
>> use the specified afid on Tattach. It is not hard to put it back.
>
> That sounds nice to me, I would love to see it back. Was there a
> problem with it?
>

I don't think there was a problem, I think it just got accidentally squashed.
patches gladly accepted :)

       -eric

Re: [9fans] v9fs question

[Latchesar Ionkov]

On Tue, Jul 14, 2009 at 1:34 AM, sqweek<sqweek@gmail.com> wrote:
>  Can't help you there - I'm not sure it makes sense to try and put
> factotum's functionality in the linux kernel... Is there some problem
> with the private namespace/individual user mount approach?
> -sqweek

I don't want to put the authentication in the kernel, but somehow to
allow user space programs to create and manipulate authentication
fids. One option would be to expose the afids in /proc or /sys, but
then it is hard to figure out what mount they belong to. Another
option is for every mount, v9fs serves mntpt/.afids directory at the
top of the mountpoint.

Or, as Ron suggested, just forget about multiple users and make it
work for a single one.

Thanks,
    Lucho