This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using thread-specific credentials on Linux in Samba with glibc.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]