Re: [PATCH] 9p: attach-per-user

2007-09-13 Thread Eric Van Hensbergen
On 9/12/07, Latchesar Ionkov <[EMAIL PROTECTED]> wrote:
>
> - allow only one user to access the tree (access=)
>  Only the user with uid can access the v9fs tree. Other users that attempt
>  to access it will get EPERM error.
>

While access= and dfltuid= creates an interesting
flexibility in the way things can be used, I'm wondering if
access= dfltuid=DEFAULT_UID is intuitive, it might be nice for
the default behavior to be setting defltuid to the uid specified in
access when that access option is used.  This can be overridden with
the dfltuid option, but I think it makes more sense to attach as the
uid you are restricting access to.

If that's the way we want to go, I think that can be handled in a
separate patch.

I've merged this stuff into my test tree, as soon as regressions pass
and I confirm they compile clean on another architecture I'll push
them into my devel to be picked up by -mm.

 -eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] 9p: attach-per-user

2007-09-13 Thread Eric Van Hensbergen
On 9/12/07, Latchesar Ionkov [EMAIL PROTECTED] wrote:

 - allow only one user to access the tree (access=uid)
  Only the user with uid can access the v9fs tree. Other users that attempt
  to access it will get EPERM error.


While access=uid and dfltuid=some-other-uid creates an interesting
flexibility in the way things can be used, I'm wondering if
access=uid dfltuid=DEFAULT_UID is intuitive, it might be nice for
the default behavior to be setting defltuid to the uid specified in
access when that access option is used.  This can be overridden with
the dfltuid option, but I think it makes more sense to attach as the
uid you are restricting access to.

If that's the way we want to go, I think that can be handled in a
separate patch.

I've merged this stuff into my test tree, as soon as regressions pass
and I confirm they compile clean on another architecture I'll push
them into my devel to be picked up by -mm.

 -eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] 9p: attach-per-user

2007-09-12 Thread Latchesar Ionkov
The 9P2000 protocol requires the authentication and permission checks to be
done in the file server. For that reason every user that accesses the file
server tree has to authenticate and attach to the server separately.
Multiple users can share the same connection to the server.

Currently v9fs does a single attach and executes all I/O operations as a
single user. This makes using v9fs in multiuser environment unsafe as it
depends on the client doing the permission checking.

This patch improves the 9P2000 support by allowing every user to attach
separately. The patch defines three modes of access (new mount option
'access'):

- attach-per-user (access=user) (default mode for 9P2000.u)
 If a user tries to access a file served by v9fs for the first time, v9fs
 sends an attach command to the server (Tattach) specifying the user. If
 the attach succeeds, the user can access the v9fs tree.
 As there is no uname->uid (string->integer) mapping yet, this mode works
 only with the 9P2000.u dialect.

- allow only one user to access the tree (access=)
 Only the user with uid can access the v9fs tree. Other users that attempt
 to access it will get EPERM error.

- do all operations as a single user (access=any) (default for 9P2000)
 V9fs does a single attach and all operations are done as a single user.
 If this mode is selected, the v9fs behavior is identical with the current
 one.

Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]>

---
commit c3daf49339c2ba13b1d8bc5087c196093f2f78f5
tree a401d3d055bbfa3be2a4c7259f3b25f81f8c1272
parent 13bf527796712619df072c0963e3f6c8c00189b8
author Latchesar Ionkov <[EMAIL PROTECTED](none)> Wed, 12 Sep 2007 22:38:59 
-0600
committer Latchesar Ionkov <[EMAIL PROTECTED](none)> Wed, 12 Sep 2007 22:38:59 
-0600

 Documentation/filesystems/9p.txt |   10 ++
 fs/9p/fid.c  |  157 ++
 fs/9p/v9fs.c |   67 +---
 fs/9p/v9fs.h |   11 ++-
 fs/9p/vfs_inode.c|   20 ++---
 include/net/9p/9p.h  |7 +-
 include/net/9p/client.h  |5 +
 net/9p/client.c  |   10 +-
 net/9p/conv.c|   32 +++-
 9 files changed, 247 insertions(+), 72 deletions(-)

diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index e694cd1..d6fd6c6 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -88,6 +88,16 @@ OPTIONS
This can be used to share devices/named pipes/sockets between
hosts.  This functionality will be expanded in later versions.
 
+  access   there are three access modes.
+   user  = if a user tries to access a file on v9fs
+   filesystem for the first time, v9fs sends an
+   attach command (Tattach) for that user.
+   This is the default mode.
+= allows only user with uid= to access
+   the files on the mounted filesystem
+   any   = v9fs does single attach and performs all
+   operations as one user
+
 RESOURCES
 =
 
diff --git a/fs/9p/fid.c b/fs/9p/fid.c
index 15e05a1..b364da7 100644
--- a/fs/9p/fid.c
+++ b/fs/9p/fid.c
@@ -1,6 +1,7 @@
 /*
  * V9FS FID Management
  *
+ *  Copyright (C) 2007 by Latchesar Ionkov <[EMAIL PROTECTED]>
  *  Copyright (C) 2005, 2006 by Eric Van Hensbergen <[EMAIL PROTECTED]>
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -34,9 +35,9 @@
 #include "fid.h"
 
 /**
- * v9fs_fid_insert - add a fid to a dentry
+ * v9fs_fid_add - add a fid to a dentry
+ * @dentry: dentry that the fid is being added to
  * @fid: fid to add
- * @dentry: dentry that it is being added to
  *
  */
 
@@ -66,52 +67,144 @@ int v9fs_fid_add(struct dentry *dentry, struct p9_fid *fid)
 }
 
 /**
- * v9fs_fid_lookup - return a locked fid from a dentry
+ * v9fs_fid_find - retrieve a fid that belongs to the specified uid
  * @dentry: dentry to look for fid in
- *
- * find a fid in the dentry, obtain its semaphore and return a reference to it.
- * code calling lookup is responsible for releasing lock
- *
- * TODO: only match fids that have the same uid as current user
+ * @uid: return fid that belongs to the specified user
+ * @any: if non-zero, return any fid associated with the dentry
  *
  */
 
-struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
+static struct p9_fid *v9fs_fid_find(struct dentry *dentry, u32 uid, int any)
 {
struct v9fs_dentry *dent;
-   struct p9_fid *fid;
-
-   P9_DPRINTK(P9_DEBUG_VFS, " dentry: %s (%p)\n", dentry->d_iname, dentry);
-   dent = dentry->d_fsdata;
-   if (dent)
-   fid = list_entry(dent->fidlist.next, struct p9_fid, dlist);
-   else
-   fid = ERR_PTR(-EBADF);
+   struct p9_fid *fid, *ret;
+
+   

[PATCH] 9p: attach-per-user

2007-09-12 Thread Latchesar Ionkov
The 9P2000 protocol requires the authentication and permission checks to be
done in the file server. For that reason every user that accesses the file
server tree has to authenticate and attach to the server separately.
Multiple users can share the same connection to the server.

Currently v9fs does a single attach and executes all I/O operations as a
single user. This makes using v9fs in multiuser environment unsafe as it
depends on the client doing the permission checking.

This patch improves the 9P2000 support by allowing every user to attach
separately. The patch defines three modes of access (new mount option
'access'):

- attach-per-user (access=user) (default mode for 9P2000.u)
 If a user tries to access a file served by v9fs for the first time, v9fs
 sends an attach command to the server (Tattach) specifying the user. If
 the attach succeeds, the user can access the v9fs tree.
 As there is no uname-uid (string-integer) mapping yet, this mode works
 only with the 9P2000.u dialect.

- allow only one user to access the tree (access=uid)
 Only the user with uid can access the v9fs tree. Other users that attempt
 to access it will get EPERM error.

- do all operations as a single user (access=any) (default for 9P2000)
 V9fs does a single attach and all operations are done as a single user.
 If this mode is selected, the v9fs behavior is identical with the current
 one.

Signed-off-by: Latchesar Ionkov [EMAIL PROTECTED]

---
commit c3daf49339c2ba13b1d8bc5087c196093f2f78f5
tree a401d3d055bbfa3be2a4c7259f3b25f81f8c1272
parent 13bf527796712619df072c0963e3f6c8c00189b8
author Latchesar Ionkov [EMAIL PROTECTED](none) Wed, 12 Sep 2007 22:38:59 
-0600
committer Latchesar Ionkov [EMAIL PROTECTED](none) Wed, 12 Sep 2007 22:38:59 
-0600

 Documentation/filesystems/9p.txt |   10 ++
 fs/9p/fid.c  |  157 ++
 fs/9p/v9fs.c |   67 +---
 fs/9p/v9fs.h |   11 ++-
 fs/9p/vfs_inode.c|   20 ++---
 include/net/9p/9p.h  |7 +-
 include/net/9p/client.h  |5 +
 net/9p/client.c  |   10 +-
 net/9p/conv.c|   32 +++-
 9 files changed, 247 insertions(+), 72 deletions(-)

diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index e694cd1..d6fd6c6 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -88,6 +88,16 @@ OPTIONS
This can be used to share devices/named pipes/sockets between
hosts.  This functionality will be expanded in later versions.
 
+  access   there are three access modes.
+   user  = if a user tries to access a file on v9fs
+   filesystem for the first time, v9fs sends an
+   attach command (Tattach) for that user.
+   This is the default mode.
+   uid = allows only user with uid=uid to access
+   the files on the mounted filesystem
+   any   = v9fs does single attach and performs all
+   operations as one user
+
 RESOURCES
 =
 
diff --git a/fs/9p/fid.c b/fs/9p/fid.c
index 15e05a1..b364da7 100644
--- a/fs/9p/fid.c
+++ b/fs/9p/fid.c
@@ -1,6 +1,7 @@
 /*
  * V9FS FID Management
  *
+ *  Copyright (C) 2007 by Latchesar Ionkov [EMAIL PROTECTED]
  *  Copyright (C) 2005, 2006 by Eric Van Hensbergen [EMAIL PROTECTED]
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -34,9 +35,9 @@
 #include fid.h
 
 /**
- * v9fs_fid_insert - add a fid to a dentry
+ * v9fs_fid_add - add a fid to a dentry
+ * @dentry: dentry that the fid is being added to
  * @fid: fid to add
- * @dentry: dentry that it is being added to
  *
  */
 
@@ -66,52 +67,144 @@ int v9fs_fid_add(struct dentry *dentry, struct p9_fid *fid)
 }
 
 /**
- * v9fs_fid_lookup - return a locked fid from a dentry
+ * v9fs_fid_find - retrieve a fid that belongs to the specified uid
  * @dentry: dentry to look for fid in
- *
- * find a fid in the dentry, obtain its semaphore and return a reference to it.
- * code calling lookup is responsible for releasing lock
- *
- * TODO: only match fids that have the same uid as current user
+ * @uid: return fid that belongs to the specified user
+ * @any: if non-zero, return any fid associated with the dentry
  *
  */
 
-struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
+static struct p9_fid *v9fs_fid_find(struct dentry *dentry, u32 uid, int any)
 {
struct v9fs_dentry *dent;
-   struct p9_fid *fid;
-
-   P9_DPRINTK(P9_DEBUG_VFS,  dentry: %s (%p)\n, dentry-d_iname, dentry);
-   dent = dentry-d_fsdata;
-   if (dent)
-   fid = list_entry(dent-fidlist.next, struct p9_fid, dlist);
-   else
-   fid = ERR_PTR(-EBADF);
+   struct p9_fid *fid, *ret;
+
+   

Re: [V9fs-developer] [PATCH] 9p: attach-per-user

2007-09-11 Thread Eric Van Hensbergen
On 9/3/07, Latchesar Ionkov <[EMAIL PROTECTED]> wrote:
>
> This patch improves the 9P2000 support by allowing every user to attach
> separately. The patch defines three modes of access (new mount option
> 'access'):
>

nit picks:
   * you added/changed options without updated Documentation/filesystems/9p.txt
   * you changed v9fs->extended to be part of a flags structure, that
should have been
   a separate patch
   * rename of options should have been done in a separate patch

> - attach-per-user (access=user)
>  If a user tries to access a file served by v9fs for the first time, v9fs
>  sends an attach command to the server (Tattach) specifying the user. If
>  the attach succeeds, the user can access the v9fs tree.
>  As there is no uname->uid (string->integer) mapping yet, this mode works
>  only with the 9P2000.u dialect.
>
> - allow only one user to access the tree (access=)
>  Only the user with uid can access the v9fs tree. Other users that attempt
>  to access it will get EPERM error.
>
> - do all operations as a single user (access=any)
>  V9fs does a single attach and all operations are done as a single user.
>  If this mode is selected, the v9fs behavior is identical with the current
>  one.
>

Which option is default?

>
>  /**
> - * v9fs_fid_insert - add a fid to a dentry
> + * v9fs_fid_add - add a fid to a dentry
> + * @dentry: dentry that the fid is being added to
>   * @fid: fid to add
> - * @dentry: dentry that it is being added to
>   *
>   */
>
> @@ -66,52 +67,144 @@ int v9fs_fid_add(struct dentry *dentry, struct p9_fid 
> *fid)
>  }

Even small cleanups like this should probably be confined to a
separate patch if they are unrelated.

>
> -struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
> +static struct p9_fid *v9fs_fid_find(struct dentry *dentry, u32 uid, int any)
>  {
...
>
> -struct p9_fid *v9fs_fid_clone(struct dentry *dentry)
> +struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
>  {
...
> +
> +struct p9_fid *v9fs_fid_clone(struct dentry *dentry)
> +{

The way the patch got formatted, these look like compulsive
renames..but there's an added function and then changes to the other
two.  I think it might be because of the way you ordered the
functions.  Put new functions after the old functions and maybe this
won't happen.  And clone seems to have lost his function header.  The
code is pretty inconsistent about those these days, but I'd like to do
an audit soon and make sure we have proper comment blocks where
appropriate.

scripts/checkpatch.pl reports:

ERROR: need a space before the open parenthesis '('
#244: FILE: fs/9p/fid.c:147:
+   for(ds = dentry; !IS_ROOT(ds); ds = ds->d_parent)

ERROR: need a space before the open parenthesis '('
#275: FILE: fs/9p/fid.c:178:
+   for(d = dentry, i = n; i >= 0; i--, d = d->d_parent)

Please fix up these small bits and resubmit.

 -eric


Also, go ahead and cc: me directly on patches, for some reason this
one missed my normal filters and got lost.  If I'm directly cc:'d it
will pop to the top of my inbox.

   -eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [V9fs-developer] [PATCH] 9p: attach-per-user

2007-09-11 Thread Eric Van Hensbergen
On 9/3/07, Latchesar Ionkov [EMAIL PROTECTED] wrote:

 This patch improves the 9P2000 support by allowing every user to attach
 separately. The patch defines three modes of access (new mount option
 'access'):


nit picks:
   * you added/changed options without updated Documentation/filesystems/9p.txt
   * you changed v9fs-extended to be part of a flags structure, that
should have been
   a separate patch
   * rename of options should have been done in a separate patch

 - attach-per-user (access=user)
  If a user tries to access a file served by v9fs for the first time, v9fs
  sends an attach command to the server (Tattach) specifying the user. If
  the attach succeeds, the user can access the v9fs tree.
  As there is no uname-uid (string-integer) mapping yet, this mode works
  only with the 9P2000.u dialect.

 - allow only one user to access the tree (access=uid)
  Only the user with uid can access the v9fs tree. Other users that attempt
  to access it will get EPERM error.

 - do all operations as a single user (access=any)
  V9fs does a single attach and all operations are done as a single user.
  If this mode is selected, the v9fs behavior is identical with the current
  one.


Which option is default?


  /**
 - * v9fs_fid_insert - add a fid to a dentry
 + * v9fs_fid_add - add a fid to a dentry
 + * @dentry: dentry that the fid is being added to
   * @fid: fid to add
 - * @dentry: dentry that it is being added to
   *
   */

 @@ -66,52 +67,144 @@ int v9fs_fid_add(struct dentry *dentry, struct p9_fid 
 *fid)
  }

Even small cleanups like this should probably be confined to a
separate patch if they are unrelated.


 -struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
 +static struct p9_fid *v9fs_fid_find(struct dentry *dentry, u32 uid, int any)
  {
...

 -struct p9_fid *v9fs_fid_clone(struct dentry *dentry)
 +struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
  {
...
 +
 +struct p9_fid *v9fs_fid_clone(struct dentry *dentry)
 +{

The way the patch got formatted, these look like compulsive
renames..but there's an added function and then changes to the other
two.  I think it might be because of the way you ordered the
functions.  Put new functions after the old functions and maybe this
won't happen.  And clone seems to have lost his function header.  The
code is pretty inconsistent about those these days, but I'd like to do
an audit soon and make sure we have proper comment blocks where
appropriate.

scripts/checkpatch.pl reports:

ERROR: need a space before the open parenthesis '('
#244: FILE: fs/9p/fid.c:147:
+   for(ds = dentry; !IS_ROOT(ds); ds = ds-d_parent)

ERROR: need a space before the open parenthesis '('
#275: FILE: fs/9p/fid.c:178:
+   for(d = dentry, i = n; i = 0; i--, d = d-d_parent)

Please fix up these small bits and resubmit.

 -eric


Also, go ahead and cc: me directly on patches, for some reason this
one missed my normal filters and got lost.  If I'm directly cc:'d it
will pop to the top of my inbox.

   -eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] 9p: attach-per-user

2007-09-03 Thread Latchesar Ionkov
The 9P2000 protocol requires the authentication and permission checks to be
done in the file server. For that reason every user that accesses the file
server tree has to authenticate and attach to the server separately.
Multiple users can share the same connection to the server.

Currently v9fs does a single attach and executes all I/O operations as a
single user. This makes using v9fs in multiuser environment unsafe as it
depends on the client doing the permission checking.

This patch improves the 9P2000 support by allowing every user to attach
separately. The patch defines three modes of access (new mount option
'access'):

- attach-per-user (access=user)
 If a user tries to access a file served by v9fs for the first time, v9fs
 sends an attach command to the server (Tattach) specifying the user. If
 the attach succeeds, the user can access the v9fs tree.
 As there is no uname->uid (string->integer) mapping yet, this mode works
 only with the 9P2000.u dialect.

- allow only one user to access the tree (access=)
 Only the user with uid can access the v9fs tree. Other users that attempt
 to access it will get EPERM error.

- do all operations as a single user (access=any)
 V9fs does a single attach and all operations are done as a single user.
 If this mode is selected, the v9fs behavior is identical with the current
 one.

The patch also renames uid and gid options to dfltuid and dfltgid. The new
names describe better the values they set.

Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]>

---
commit 836f166ce5578b084c1cd75807e29474586bab61
tree c7e1eb631c3e6b0f1cd773ae7884379776c2857d
parent 3ec910913c8c743cbe4cd9cdde17df26a75d02ec
author Latchesar Ionkov <[EMAIL PROTECTED](none)> Mon, 03 Sep 2007 14:09:29 
-0600
committer Latchesar Ionkov <[EMAIL PROTECTED](none)> Mon, 03 Sep 2007 14:09:29 
-0600

 fs/9p/fid.c |  157 +--
 fs/9p/v9fs.c|   87 +++---
 fs/9p/v9fs.h|   27 +++-
 fs/9p/vfs_inode.c   |   52 
 include/net/9p/9p.h |7 +-
 include/net/9p/client.h |5 +
 net/9p/client.c |   10 ++-
 net/9p/conv.c   |   32 --
 8 files changed, 278 insertions(+), 99 deletions(-)

diff --git a/fs/9p/fid.c b/fs/9p/fid.c
index 15e05a1..b16b14b 100644
--- a/fs/9p/fid.c
+++ b/fs/9p/fid.c
@@ -1,6 +1,7 @@
 /*
  * V9FS FID Management
  *
+ *  Copyright (C) 2007 by Latchesar Ionkov <[EMAIL PROTECTED]>
  *  Copyright (C) 2005, 2006 by Eric Van Hensbergen <[EMAIL PROTECTED]>
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -34,9 +35,9 @@
 #include "fid.h"
 
 /**
- * v9fs_fid_insert - add a fid to a dentry
+ * v9fs_fid_add - add a fid to a dentry
+ * @dentry: dentry that the fid is being added to
  * @fid: fid to add
- * @dentry: dentry that it is being added to
  *
  */
 
@@ -66,52 +67,144 @@ int v9fs_fid_add(struct dentry *dentry, struct p9_fid *fid)
 }
 
 /**
- * v9fs_fid_lookup - return a locked fid from a dentry
+ * v9fs_fid_find - retrieve a fid that belongs to the specified uid
  * @dentry: dentry to look for fid in
- *
- * find a fid in the dentry, obtain its semaphore and return a reference to it.
- * code calling lookup is responsible for releasing lock
- *
- * TODO: only match fids that have the same uid as current user
+ * @uid: return fid that belongs to the specified user
+ * @any: if non-zero, return any fid associated with the dentry
  *
  */
 
-struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
+static struct p9_fid *v9fs_fid_find(struct dentry *dentry, u32 uid, int any)
 {
struct v9fs_dentry *dent;
-   struct p9_fid *fid;
-
-   P9_DPRINTK(P9_DEBUG_VFS, " dentry: %s (%p)\n", dentry->d_iname, dentry);
-   dent = dentry->d_fsdata;
-   if (dent)
-   fid = list_entry(dent->fidlist.next, struct p9_fid, dlist);
-   else
-   fid = ERR_PTR(-EBADF);
+   struct p9_fid *fid, *ret;
+
+   P9_DPRINTK(P9_DEBUG_VFS, " dentry: %s (%p) uid %d any %d\n",
+   dentry->d_iname, dentry, uid, any);
+   dent = (struct v9fs_dentry *) dentry->d_fsdata;
+   ret = NULL;
+   if (dent) {
+   spin_lock(>lock);
+   list_for_each_entry(fid, >fidlist, dlist) {
+   if (any || fid->uid == uid) {
+   ret = fid;
+   break;
+   }
+   }
+   spin_unlock(>lock);
+   }
 
-   P9_DPRINTK(P9_DEBUG_VFS, " fid: %p\n", fid);
-   return fid;
+   return ret;
 }
 
 /**
- * v9fs_fid_clone - lookup the fid for a dentry, clone a private copy and
- * release it
+ * v9fs_fid_lookup - lookup for a fid, try to walk if not found
  * @dentry: dentry to look for fid in
  *
- * find a fid in the dentry and then clone to a new private fid
- *
- * TODO: only match fids that have the same uid as current user
- *
+ * Look for a fid in the 

[PATCH] 9p: attach-per-user

2007-09-03 Thread Latchesar Ionkov
The 9P2000 protocol requires the authentication and permission checks to be
done in the file server. For that reason every user that accesses the file
server tree has to authenticate and attach to the server separately.
Multiple users can share the same connection to the server.

Currently v9fs does a single attach and executes all I/O operations as a
single user. This makes using v9fs in multiuser environment unsafe as it
depends on the client doing the permission checking.

This patch improves the 9P2000 support by allowing every user to attach
separately. The patch defines three modes of access (new mount option
'access'):

- attach-per-user (access=user)
 If a user tries to access a file served by v9fs for the first time, v9fs
 sends an attach command to the server (Tattach) specifying the user. If
 the attach succeeds, the user can access the v9fs tree.
 As there is no uname-uid (string-integer) mapping yet, this mode works
 only with the 9P2000.u dialect.

- allow only one user to access the tree (access=uid)
 Only the user with uid can access the v9fs tree. Other users that attempt
 to access it will get EPERM error.

- do all operations as a single user (access=any)
 V9fs does a single attach and all operations are done as a single user.
 If this mode is selected, the v9fs behavior is identical with the current
 one.

The patch also renames uid and gid options to dfltuid and dfltgid. The new
names describe better the values they set.

Signed-off-by: Latchesar Ionkov [EMAIL PROTECTED]

---
commit 836f166ce5578b084c1cd75807e29474586bab61
tree c7e1eb631c3e6b0f1cd773ae7884379776c2857d
parent 3ec910913c8c743cbe4cd9cdde17df26a75d02ec
author Latchesar Ionkov [EMAIL PROTECTED](none) Mon, 03 Sep 2007 14:09:29 
-0600
committer Latchesar Ionkov [EMAIL PROTECTED](none) Mon, 03 Sep 2007 14:09:29 
-0600

 fs/9p/fid.c |  157 +--
 fs/9p/v9fs.c|   87 +++---
 fs/9p/v9fs.h|   27 +++-
 fs/9p/vfs_inode.c   |   52 
 include/net/9p/9p.h |7 +-
 include/net/9p/client.h |5 +
 net/9p/client.c |   10 ++-
 net/9p/conv.c   |   32 --
 8 files changed, 278 insertions(+), 99 deletions(-)

diff --git a/fs/9p/fid.c b/fs/9p/fid.c
index 15e05a1..b16b14b 100644
--- a/fs/9p/fid.c
+++ b/fs/9p/fid.c
@@ -1,6 +1,7 @@
 /*
  * V9FS FID Management
  *
+ *  Copyright (C) 2007 by Latchesar Ionkov [EMAIL PROTECTED]
  *  Copyright (C) 2005, 2006 by Eric Van Hensbergen [EMAIL PROTECTED]
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -34,9 +35,9 @@
 #include fid.h
 
 /**
- * v9fs_fid_insert - add a fid to a dentry
+ * v9fs_fid_add - add a fid to a dentry
+ * @dentry: dentry that the fid is being added to
  * @fid: fid to add
- * @dentry: dentry that it is being added to
  *
  */
 
@@ -66,52 +67,144 @@ int v9fs_fid_add(struct dentry *dentry, struct p9_fid *fid)
 }
 
 /**
- * v9fs_fid_lookup - return a locked fid from a dentry
+ * v9fs_fid_find - retrieve a fid that belongs to the specified uid
  * @dentry: dentry to look for fid in
- *
- * find a fid in the dentry, obtain its semaphore and return a reference to it.
- * code calling lookup is responsible for releasing lock
- *
- * TODO: only match fids that have the same uid as current user
+ * @uid: return fid that belongs to the specified user
+ * @any: if non-zero, return any fid associated with the dentry
  *
  */
 
-struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
+static struct p9_fid *v9fs_fid_find(struct dentry *dentry, u32 uid, int any)
 {
struct v9fs_dentry *dent;
-   struct p9_fid *fid;
-
-   P9_DPRINTK(P9_DEBUG_VFS,  dentry: %s (%p)\n, dentry-d_iname, dentry);
-   dent = dentry-d_fsdata;
-   if (dent)
-   fid = list_entry(dent-fidlist.next, struct p9_fid, dlist);
-   else
-   fid = ERR_PTR(-EBADF);
+   struct p9_fid *fid, *ret;
+
+   P9_DPRINTK(P9_DEBUG_VFS,  dentry: %s (%p) uid %d any %d\n,
+   dentry-d_iname, dentry, uid, any);
+   dent = (struct v9fs_dentry *) dentry-d_fsdata;
+   ret = NULL;
+   if (dent) {
+   spin_lock(dent-lock);
+   list_for_each_entry(fid, dent-fidlist, dlist) {
+   if (any || fid-uid == uid) {
+   ret = fid;
+   break;
+   }
+   }
+   spin_unlock(dent-lock);
+   }
 
-   P9_DPRINTK(P9_DEBUG_VFS,  fid: %p\n, fid);
-   return fid;
+   return ret;
 }
 
 /**
- * v9fs_fid_clone - lookup the fid for a dentry, clone a private copy and
- * release it
+ * v9fs_fid_lookup - lookup for a fid, try to walk if not found
  * @dentry: dentry to look for fid in
  *
- * find a fid in the dentry and then clone to a new private fid
- *
- * TODO: only match fids that have the same uid as current user
- *
+ * Look for a fid in the specified