> Sorry. I meant to have the library do the change itself in execve > when it's needed (since usually it's a nop) instead of expecting the > exec server to do it.
Just to keep the record straight, I was talking about having the filesystem implementing file_exec do it (that's where the only auth diddling is, the exec server doesn't do it). But having the user do it is a better plan. I don't know why I didn't think of that in the first place. It avoids the whole issue of the filesystem having to either trust or deal with a user-supplied auth port even with a svuid/svgid change is required. The only drawback I see is in the case when svuid!=euid or svgid!=egid, and you are executing an sugid file. The user will reauthenticate everything for the svuid=euid, svgid=egid change and then the filesystem will reauthenticate everything again to do the suid/sgid. So, a sugid program that execs another sugid program directly without an intervening exec of a non-suid program--a pretty rare event, I would guess. > But there might be a security reason why we have to force the change > to be made. But I can't possibly see what that would be. I don't think any concept of security is sensical for non-sugid execs with EXEC_SECURE. The user who made the call will always be able to grab the process by its scrawny little task port and diddle its ports out the wazoo. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
