summaryrefslogtreecommitdiffstats
path: root/net/9p/client.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2015-04-03 03:47:49 +0200
committerAl Viro <viro@zeniv.linux.org.uk>2015-04-12 04:28:28 +0200
commit21c9f5ccb103868c730aec6f8548e144ec397fed (patch)
treed82387bd64ae1e98c40ad2f244d1584ec5c4f47f /net/9p/client.c
parent9p: we are leaking glock.client_id in v9fs_file_getlock() (diff)
downloadlinux-21c9f5ccb103868c730aec6f8548e144ec397fed.tar.xz
linux-21c9f5ccb103868c730aec6f8548e144ec397fed.zip
p9_client_attach(): set fid->uid correctly
it's almost always equal to current_fsuid(), but there's an exception - if the first writeback fid is opened by non-root *and* that happens before root has done any lookups in /, we end up doing attach for root. The current code leaves the resulting FID owned by root from the server POV and by non-root from the client one. Unfortunately, it means that e.g. massive dcache eviction will leave that user buggered - they'll end up redoing walks from / *and* picking that FID every time. As soon as they try to create something, the things will get nasty. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to '')
-rw-r--r--net/9p/client.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/net/9p/client.c b/net/9p/client.c
index 18583bb89db6..6f4c4c88db84 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -1116,6 +1116,7 @@ struct p9_fid *p9_client_attach(struct p9_client *clnt, struct p9_fid *afid,
fid = NULL;
goto error;
}
+ fid->uid = n_uname;
req = p9_client_rpc(clnt, P9_TATTACH, "ddss?u", fid->fid,
afid ? afid->fid : P9_NOFID, uname, aname, n_uname);