On Tuesday, April 09, 2013 00:33:32 Boaz Harrosh wrote: > 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. In our case, true. But this is a syscall and we will be stuck with it forever. The reason for this syscall request, along with the locking request it that they were too narrow in scope. This is, or can be, and issue for non- threaded apps that do use pollling, signaling, and all the rest. > > > 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? I checked with Herb et al and they have a hack for CIFS (which scares me a bit...) but they confirmed that stock FreeBSD has the creds as a property of the proc, not a thread. Their structure sounds similar to Mach, aka OSF/1, aka Digital UNIX which had thread structs only contain the thread specific state and left things like creds and open fds in the proc struct. To handle their CIFS need, they added a creds_like (emphasis on the "like") struct that gets allocated on a CIFS related event (not sure on details) but this is specific to their kernel. Stock FreeBSD doesn't have it and it doesn't sound like we can use it. > > > 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. And my comments about selinux are to explore/define/get_alarmed about that dimension as well given that selinux and friends are another layer/alternate universe of access control. Hmm. Might need a flags arg in the api... > > Thanks > Boaz -- Jim Lieb Linux Systems Engineer Panasas Inc. -- 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
