Alexander Boström <[EMAIL PROTECTED]> writes: > ons 2005-09-21 klockan 12:04 -0700 skrev Russ Allbery:
>> Could you make this an afsd startup option? There's an open bug in >> Debian that would be at least partially addressed by letting people run >> AFS in this mode (someone asking for a way to escape PAGs), but >> compile-time options are a real pain for distributions. We can't >> really ship multiple versions built with different options easily. > The patch does add a runtime option, Oh, I see! You did it as a module parameter. Yes, that's a perfectly sensible thing to do for a Linux solution given the concerns you noted below. I'm sorry for not paying close enough attention. I think an afsd option would be somewhat better in that it would give all platforms the advantage of this choice, but it would require setting some sort of global module state and then checking it in the setgroups wrapper rather than just not installing the wrapper at all, which isn't quite as clean or as easy to code. > Anyway, while I still wouldn't mind having the above option, I see now > that it would probably be a better idea to add an AFSCALL_UNSETPAG that > returns the process to the default PAG. Only root should be allowed to > do that. This should be portable across different operating systems, > hopefully including any future in-kernel keyring based PAG > implementations. This would certainly be the ideal solution, since then we could provide an unpagsh command that does the equivalent of pagsh but in reverse. I'm not sure, though, that it wouldn't be good to have both. Adding the unsetpag system call still requires that something call it where appropriate, and of course we'll never get all of the software modified to call an AFS-specific function (nor, really, would that be the right thing to do). For servers without untrusted user accounts, running without the setgroups wrapper often has some appeal. What do other people think about this? I'd like to see some sort of solution added. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
