Yes, that seems to be a bona fide bug based on a misreading of the standard. The language is not really all that clear, but the behavior of other systems is consistent so we can tell how to read it. That is, svuid=euid and svgid=egid are done *on every exec*, not just on s[ugi]id ones.
This is unfortunate for the Hurd, because as things are defined now it would require some additional RPCs to the auth server for every exec. This has several issues. First, it's just more RPCs to slow the exec down. For a non-secure exec, the filesystem really doesn't care if the auth port passed in file_exec is totally bogus. So you have to treat this differently, especially for things like fakeauth to have a hope of working. The common case is that no IDs need to change because euid==svuid and egid==svgid already, so you would like to avoid the whole mess for that. But as things are specified now, there is no way to know that without doing an auth_getids RPC on the auth port. The only thing I see is to presume that the authentication of the file port being used for file_exec matches the auth port in question, and so the filesystem can just examine its own record to check whether anything needs to be done. That would be a new assumption in the semantics of file_exec now, but it's an assumption that's true for all existing uses of file_exec AFAIK. We could add a new EXEC_* flag bit to assert this is ok, which execve et al would use. (The meaning of this flag being that if the receiving protid has svuid==euid and svgid==egid then the auth port doesn't need to be modified for a non-sugid exec.) I think the first thing to do, regardless of all else, is to change the fshelp_exec_reauth interface so that the entire question can be resolved in that function. I propose to change netfs and diskfs so they call fshelp_exec_reauth for every exec, not just sugid ones. I also want to replace the callback function by just passing the iouser; that is all that's needed to replace the existing two (identical) callback functions used by netfs/diskfs, and gives the necessary information for the plan I described above. I'm inclined to make this change now just because it reduces some code duplication and simplifies some unnecessary hair, without necessarily changing the behavior at all. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
