This is the mail archive of the libc-alpha@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: [MTASCsft PATCH 37/??] MT-, AS- and AC-Safety docs: manual/users.texi


On 02/02/2014 12:54 PM, Joseph S. Myers wrote:
> On Fri, 31 Jan 2014, Carlos O'Donell wrote:
> 
>> In glibc this is implemented via setXid and has to iterate over all
>> threads making them call signal handlers to call setXid themselves
>> because the kernel does not provide an atomic way to change all of
>> the gid's at the same time for the "process."
> 
> Really I'd suggest working with the kernel people to get new syscalls for 
> atomically changing ids across an entire process, as suggested in bug 
> 13347 comment 5, to fix the problems of partial failure as well as not 
> being fully safe.  Don't assume that if the kernel people refused in 2004 
> (as said in the libc-hacker message you found) they'd refuse now - all the 
> security issues associated with set*id failing when programs didn't test 
> for it are more recent than then, so the issues are likely to be 
> considered more significant now than in 2004.

I fully agree.

> (More generally, it might be good to have a list of cases where we think 
> there are deficiencies in the kernel/userspace interface that cause 
> problems for implementing something in glibc, along with proposed fixes 
> and whether and when those have been proposed for kernel inclusion.  I 
> doubt this is the only one.)

I have added a "Linux Kernel" section to the master todo list and added
setXid issues there. I have moved "Synchronizing Headers" to that category
since it's a kernel/glibc issue that we've begun solving already.

Cheers,
Carlos.


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