{"action":"created","issue":{"url":"https://api.github.com/repos/mar-file-system/marfs/issues/79","labels_url":"https://api.github.com/repos/mar-file-system/marfs/issues/79/labels{/name}","comments_url":"https://api.github.com/repos/mar-file-system/marfs/issues/79/comments","events_url":"https://api.github.com/repos/mar-file-system/marfs/issues/79/events","html_url":"https://github.com/mar-file-system/marfs/issues/79","id":125708538,"number":79,"title":"linux bug with setfsgid() accessing dirs with group=root ","user":{"login":"jti-lanl","id":8238841,"avatar_url":"https://avatars.githubusercontent.com/u/8238841?v=3","gravatar_id":"","url":"https://api.github.com/users/jti-lanl","html_url":"https://github.com/jti-lanl","followers_url":"https://api.github.com/users/jti-lanl/followers","following_url":"https://api.github.com/users/jti-lanl/following{/other_user}","gists_url":"https://api.github.com/users/jti-lanl/gists{/gist_id}","starred_url":"https://api.github.com/users/jti-lanl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jti-lanl/subscriptions","organizations_url":"https://api.github.com/users/jti-lanl/orgs","repos_url":"https://api.github.com/users/jti-lanl/repos","events_url":"https://api.github.com/users/jti-lanl/events{/privacy}","received_events_url":"https://api.github.com/users/jti-lanl/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-01-08T22:34:21Z","updated_at":"2016-01-11T18:15:10Z","closed_at":null,"body":"There appears to be a Linux bug in the implementation of setfsgid, or rather in file accesses which depend on it.\r\n\r\nAssume a process running as root (like a fuse-mount).  After setting fsuid/fsgid from root/root to the uid/gid of a regular user, I can still read directories that are owned by root:root, chmod 770.  In other words (and only in the case of directories with group = 0), it seems that Linux 2.6.32-504.12.2.2chaos.ch5.3.x86_64 is ignoring the setfsgid(gid), and continuing to look at the root egid.\r\n\r\nThis linux bug (?) does not apply to fsuid (just fsgid).  For example, user 500 can **NOT** see the contents of a directory owned root:root, chmod 700.\r\n\r\nIt also doesn't apply to directories that are owned by other groups.  For example, user 500 can **NOT** see the contents of a directory that is owned 502:502, chmod 770.\r\n\r\n-\r\nSECURITY IMPLICATIONS:\r\n\r\nWe currently use setfsuid/setfsgid because these functions allow per-thread control of the apparent uid/gid used for file accesses.  This allows fuse to be multi-threaded (without locking), serving multiple users concurrently.  The bug (if I understand it correctly) only affects files that have group root, whose security depends on group-access permissions.  Many FUSE filesystems use this same technology, and so I'd guess all such implementations have this same vulnerability.  (NFS, too?)  **However, because we don't expect any files in marfs owned by root (not to mention group root), we expect this is moot, for now, in marfs.**\r\n\r\n-\r\nALTERNATIVES:\r\n\r\n(a) run fuse single-threaded, with seteuid()/setegid()\r\n\r\n(b) run fuse multi-threaded with seteuid()/setegid(), and wrap locking around all MDFS accesses.  In the simplest implementation, this would look a lot like (a).  But with some refinement, we could just wrap the MDFS interactions, which is all that matters.\r\n\r\n(c) The answer from \"asn\" in [this thread](http://stackoverflow.com/questions/1223600/change-uid-gid-only-of-one-thread-in-linux) suggests making direct syscalls to seteuid/setegid affects only the calling thread.   If so, **that would let us avoid this issue**.\r\n\r\n-\r\nTEST CODE:\r\n\r\nThis code can show the problem:\r\n\r\n[test_setfsgid_bug.c.txt](https://github.com/mar-file-system/marfs/files/83342/test_setfsgid_bug.c.txt)\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/mar-file-system/marfs/issues/comments/170638777","html_url":"https://github.com/mar-file-system/marfs/issues/79#issuecomment-170638777","issue_url":"https://api.github.com/repos/mar-file-system/marfs/issues/79","id":170638777,"user":{"login":"jti-lanl","id":8238841,"avatar_url":"https://avatars.githubusercontent.com/u/8238841?v=3","gravatar_id":"","url":"https://api.github.com/users/jti-lanl","html_url":"https://github.com/jti-lanl","followers_url":"https://api.github.com/users/jti-lanl/followers","following_url":"https://api.github.com/users/jti-lanl/following{/other_user}","gists_url":"https://api.github.com/users/jti-lanl/gists{/gist_id}","starred_url":"https://api.github.com/users/jti-lanl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jti-lanl/subscriptions","organizations_url":"https://api.github.com/users/jti-lanl/orgs","repos_url":"https://api.github.com/users/jti-lanl/repos","events_url":"https://api.github.com/users/jti-lanl/events{/privacy}","received_events_url":"https://api.github.com/users/jti-lanl/received_events","type":"User","site_admin":false},"created_at":"2016-01-11T18:15:09Z","updated_at":"2016-01-11T18:15:09Z","body":"Implemented \"(c)\" above, i.e. using \"syscall(SYS_setresuid())\" and \"syscall(SYS_setresgid)\".\r\n\r\nIt is true that these affect only the calling thread.  However, they show the exact same behavior regarding directories that are root:root rwxrwx---.\r\n\r\nI think that leaves us stuck accepting this behavior.  I'm leaving this issue open, for now, so we can be reminded of this quirk, when we're considering project status.\r\n\r\nI've adopted the setres*id*() approach, because it's more-portable and more-likely to be maintained in Linux."}}