This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Using thread-specific credentials on Linux in Samba with glibc.
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Jeremy Allison <jra at samba dot org>
- Cc: libc-help at sourceware dot org
- Date: Mon, 2 Jul 2012 22:20:36 +0530
- Subject: Re: Using thread-specific credentials on Linux in Samba with glibc.
- References: <20120702161706.GA9979@samba2>
On 2 July 2012 21:47, Jeremy Allison <jra@samba.org> wrote:
> Happily, this doesn't require any changes in
> glibc, as I have wrappers for all the credentials
> changing code in Samba that I just redirect to
> change from doing something like:
>
> ret = setresuid(ruid, euid, suid);
>
> to:
>
> ret = syscall(SYS_setresuid, ruid, euid, suid);
>
> and everything still works (modulo 32-bit/64-bit
> call differences of course :-).
>
> So my question is - can we rely on glibc not to
> break our usage of this in the future ? One of
> the Samba developers is paranoid about glibc breaking
> this ability by changing the syscall() call on
> Linux to prevent this, and he would like some reassurance
> that we can rely on this remaining possible in future
> versions of glibc on Linux.
The syscall() function implementation is pretty straightforward -- it
basically follows the ABI requirements of each architecture for the
kernel syscall interface, putting the syscall number and arguments
into the right registers/locations and then getting the return value
into the right location. Could you elaborate on what you expect to
change in this, that could be problematic? A lot of applications call
the syscall function to make indirect system calls to avoid libc
wrappers, so if there is an incompatible change here, I imagine it'll
be pretty serious trouble.
Regards,
Siddhesh
--
http://siddhesh.in