On 08/08/2013 09:37 PM, Michael Kerrisk (man-pages) wrote: > On 08/07/13 18:21, Oleg Nesterov wrote: >> On 08/06, Andy Lutomirski wrote: >>> >>> I assume that what the man page means is that the return value is >>> whatever fsgid was prior to the call. On error, fsgid isn't changed, so >>> the return value is still "current". >> >> Probably... Still >> >> On success, the previous value of fsuid is returned. >> On error, the current value of fsuid is returned. >> >> looks confusing. sys_setfsuid() always returns the old value. >> >>> (FWIW, this behavior is awful and is probably the cause of a security >>> bug or three, since success and failure are indistinguishable. >> >> At least this all looks strange. >> >> I dunno if we can change this old behaviour. I won't be surprized >> if someone already uses setfsuid(-1) as getfsuid(). >> >> And perhaps the man page should be changed. Add Michael. > > Thanks, Oleg. I've applied the following patch to setfsuid.2 > (and a similar patch to setfsgid.2). > > Cheers, > > Michael > > --- a/man2/setfsuid.2 > +++ b/man2/setfsuid.2 > @@ -67,12 +67,8 @@ matches either the real user ID, effective user ID, saved > set-user-ID, or > the current value of > .IR fsuid . > .SH RETURN VALUE > -On success, the previous value of > -.I fsuid > -is returned. > -On error, the current value of > -.I fsuid > -is returned. > +On both success and failure, > +this call returns the previous filesystem user ID of the caller. > .SH VERSIONS > This system call is present in Linux since version 1.2. > .\" This system call is present since Linux 1.1.44 > @@ -102,7 +98,16 @@ The glibc > .BR setfsuid () > wrapper function transparently deals with the variation across kernel > versions. > .SH BUGS > -No error messages of any kind are returned to the caller. > +No error indications of any kind are returned to the caller, > +and the fact that both successful and unsuccessful calls return > +the same value makes it impossible to directly determine > +whether the call succeeded or failed. > +Instead, the caller must resort to looking at the return value > +from a further call such as > +.IR setfsuid(\-1) > +(which will always fail), in order to determine if a preceding call to > +.BR setfsuid () > +changed the filesystem user ID. > At the very > least, > .B EPERM >
Is it suitable to mention this API is obsoleted and unneeded in man page ? ;-) Thanks. -- Chen Gang -- 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/
