Fixing setfsuid/setfsgid

[Florian Weimer <fweimer@redhat.com>]

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.

* 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.

* 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.

Comments?

-- 
Florian Weimer / Red Hat Product Security Team