On 08/04/13 22:45, Jim Lieb wrote: > We are setting user, primary group, and alt groups in sequence before we do > the actual work (read/write/...). This is a potential TOCTOU race. Granted, > there is little/no real atomic guarantee but implied in the syscall model is > that creds don't change for the duration of a syscall. We go back to > userspace multiple times with creds in intermediate state(s). Signals can > happen anytime but are only checked on the way back out of the syscall or we > can hold them off at critical times within a single syscall. Which syscall is > is the one where the signal occurred? In our case, we minimally use signals > (do no i/o etc.) but they are still there. If it is one syscall, we know. > signals are crap long before our case. I would not really care about signals. The performance argument is good enough for me. > We currently have an RFC implementation of a "creds wrapper" but it is still > in flux and the codiing of all these calls to "get it right" is ugly. One > call, done right would be much better. > > We also have a problem with the setgroups. We escape in Linux because the > kernel doesn't do it process wide and glibc fakes it. I don't want to depend > on that. In FreeBSD, we can't do it at all since the creds are shared at the Sachin found that FBSD might be exactly the same as Linux here. Please talk to him to make sure? > proc level. Note that I am constrained to think about portability and it's > easier to sell a new syscall than to hack fundamental kernel structures which > is why the "do to all" bit is in glibc... > But yes a new syscall with new defined semantics is definitely a better way to go. Just for the sake of thread_setgroups such a call is well worth it. Completely bypass POSIX and be done with it. So strongly yes here. Bruce, got the point? Current code with the undocumented thread_setgroups is a POSIX hack. And will break at any given moment in time. Only a new syscall with defined semantics will ever be correct. Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
