setfs[ug]id syscall return value and include/linux/security.h question

setfs[ug]id syscall return value and include/linux/security.h question

Post by Jakub Jeline » Fri, 28 Mar 2003 01:20:11



Hi!

Before include/linux/security.h was added, setfsuid/setfsgid always returned
old_fsuid, no matter if the fsuid was actually changed or not.
With the default security ops it seems to do the same, because both
security_task_setuid and security_task_post_setuid return 0, but these are
hooks which seem to return 0 on success, -errno on failure, so if some
non-default security hook is installed and ever returns -errno
in setfsuid/setfsgid, -errno will be returned from the syscall instead
of the expected old_fsuid. This makes it hard to distinguish uids
0xfffff001 .. 0xffffffff from errors of security hooks.
Shouldn't sys_setfsuid/sys_setfsgid be changed:

--- linux-2.5.66/kernel/sys.c.jj        Mon Mar 24 23:00:00 2003

 asmlinkage long sys_setfsuid(uid_t uid)
 {
        int old_fsuid;
-       int retval;
-
-       retval = security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS);
-       if (retval)
-               return retval;

        old_fsuid = current->fsuid;
+       if (security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS))
+               return old_fsuid;
+
        if (uid == current->uid || uid == current->euid ||
            uid == current->suid || uid == current->fsuid ||

                current->fsuid = uid;
        }

-       retval = security_task_post_setuid(old_fsuid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS);
-       if (retval)
-               return retval;
+       security_task_post_setuid(old_fsuid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS);

        return old_fsuid;

 asmlinkage long sys_setfsgid(gid_t gid)
 {
        int old_fsgid;
-       int retval;
-
-       retval = security_task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_FS);
-       if (retval)
-               return retval;

        old_fsgid = current->fsgid;
+       if (security_task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_FS))
+               return old_fsgid;
+
        if (gid == current->gid || gid == current->egid ||
            gid == current->sgid || gid == current->fsgid ||
            capable(CAP_SETGID))

        Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

setfs[ug]id syscall return value and include/linux/security.h question

Post by David Wagn » Fri, 28 Mar 2003 02:00:27



>Before include/linux/security.h was added, setfsuid/setfsgid always returned
>old_fsuid, no matter if the fsuid was actually changed or not.

Out of curiousity:

Do you have any idea why setfsuid() returns the old fsuid, rather than
0 or -EPERM like all the other set*id() calls?

I find it mysterious that setfsuid()'s interface is so different.
It is also strange that setfsuid() has no way to indicate whether the
call failed or succeeded.  Does this inconsistency with the rest of the
set*id() interface strike anyone else as a little odd?

It is also mysterious that there is no getfsuid() call.  One has to use
/proc to find this information.  Do you have any idea why the fsuid/fsgid
interface was designed this way?  Is this an old kludge that we now have
to live with, was it designed this way for a reason, or do we have the
opportunity to fix the semantics of the interface?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

setfs[ug]id syscall return value and include/linux/security.h question

Post by Chris Wrigh » Fri, 28 Mar 2003 04:00:21




> >Before include/linux/security.h was added, setfsuid/setfsgid always returned
> >old_fsuid, no matter if the fsuid was actually changed or not.

> Out of curiousity:

> Do you have any idea why setfsuid() returns the old fsuid, rather than
> 0 or -EPERM like all the other set*id() calls?

I agree, it seems odd.

Quote:> I find it mysterious that setfsuid()'s interface is so different.
> It is also strange that setfsuid() has no way to indicate whether the
> call failed or succeeded.  Does this inconsistency with the rest of the
> set*id() interface strike anyone else as a little odd?

You're not alone ;-)  Even the manpage suggests this is a bug.

Quote:> It is also mysterious that there is no getfsuid() call.  One has to use
> /proc to find this information.  Do you have any idea why the fsuid/fsgid
> interface was designed this way?  Is this an old kludge that we now have
> to live with, was it designed this way for a reason, or do we have the
> opportunity to fix the semantics of the interface?

I can't comment on the history of the interface.  While it's Linux
specific, I'm not sure of the legacy impact of changing the semantics of
the current interface.  Ugh.

thanks,
-chris
--
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

setfs[ug]id syscall return value and include/linux/security.h question

Post by Chris Wrigh » Fri, 28 Mar 2003 04:20:09



Quote:> Hi!

> Before include/linux/security.h was added, setfsuid/setfsgid always returned
> old_fsuid, no matter if the fsuid was actually changed or not.
> With the default security ops it seems to do the same, because both
> security_task_setuid and security_task_post_setuid return 0, but these are
> hooks which seem to return 0 on success, -errno on failure, so if some
> non-default security hook is installed and ever returns -errno
> in setfsuid/setfsgid, -errno will be returned from the syscall instead
> of the expected old_fsuid. This makes it hard to distinguish uids
> 0xfffff001 .. 0xffffffff from errors of security hooks.
> Shouldn't sys_setfsuid/sys_setfsgid be changed:

Yes, thanks for the patch.  I'll apply this to the LSM tree and push to
Linus with the next batch of changes.  It's unfortunate that the
sys_setfs[ug]id interface can't report an error.

thanks,
-chris
--
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Return value of syscalls

Hi,

while debugging glibc-2.3.1 for cris-axis-linux-gnu, I encountered a
discrepancy between code and comments explaining the return value of
syscalls of the kernel (in glibc's source, architecture specific for
cris). The comment says, values between -4095 and -1 (both inclusive)
are considered to be an error. However, the code checks the return value
to be greater or equal than -4096.

I'd like to fix that. But I need to know what's wrong, the code or the
comment. So, what values indicate an error in linux's syscalls?

Best regards, Uwe

P.S.: A look in other architecture's source in glibc makes me thing the
comment is right. I just want to make sure.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Help: multi-volume ufsdump

3. Problem relaynews: set[ug]id failed (Bad file number)

4. problem with setpgid in combination with rsh

5. [2/4]: Ext2/3 updates: Cleanup: Eliminate EXT3/2_DEF_RES[UG]ID

6. Sync on Green graphics card

7. vendor-id and device-id values in prtconf -pv

8. moving solaris

9. relaynews: set[ug]id failed (Operation not allowed)

10. SCO UNIX and sete[ug]id work around?

11. Default return value for when return() is not explicitly used on SC5.0

12. HELP: Undocumented set[ug]id programs in Solaris 2.3

13. BSM Solaris - question of return value