On Wed, 22 Jan 2014 13:40:46 +0100 Florian Weimer <fweimer@xxxxxxxxxx> wrote: > At present, setfsuid and setfsgid return the same value on success and > on error, so it is rather difficult to check for errors. Since the > userns changes at least, failure can not only be caused by lack of the > CAP_SETUID capability, but also by an out-of-memory situation. > It is awkward, but how is it ambiguous? If you get back the same value you passed in, then you know that nothing changed. I guess it could be an issue if you pass in a fsuid that's equivalent to the current one though. > * Introduce new system calls setfsuid1, fetfsgid1 which have the usual > "return -errno on failure, 0 on success" semantics. > > * Introduce getfsuid, getfsgid, so that applications can check for > failure by noting that the fs?id did not change. These system calls > might have other uses as well. Emulation in glibc by parsing > /proc/self/status is possible. > #2 sounds quite reasonable. It's simple, and having a setfsuid() without a way to definitively fetch the current value is dumb. > * Don't bother with fs?id at all anymore and attach effective security > information to descriptors, which are then inherited by the *at > functions. This is far more invasive, but would solve the > multi-threading ambiguity and could be reasonably extended to umask and > security contexts. This would need new system calls fsetuid, fsetgid, > and probably socketat (for bind/connect) and perhaps socketpairat. > (cc'ing Jim Lieb) I know that Jim had been working on something along these lines, but I don't know the current state of that work... -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
