list v. scalar assignment to E?UID, E?GID

[hvds]

I notice by code inspection that when assigning to $< in mg.c:Perl_magic_set it uses the first available of setruid, setreuid, setresuid or (with more caveats) setuid. However it only goes through that path if it's a scalar assignment: list assignments have PL_delaymagic set, and end up instead going through the code in pp_hot.c:S_aassign_uid, which uses the first available of setresuid, setreuid, setruid, setuid - a different order.

Is this a bug? I haven't checked, but I assume the same will apply to $>, $( and $) if so.

My guess is that the order doesn't matter: any of the first three that are defined will do what is needed (and if one is buggy it should be undef'd in configuration), so it's just a matter of finding one that's available on this platform. But it would be good to know for sure, and perhaps record it in a comment.

[Leont]

You can easily argue the inconsistent order is a bug, it's a bit harder to argue which order is better.

Using setreuid this way will not only change the real user id, but also the saved user id, while setruid and setresuid will not do such a thing.

The core problem is that this interface predates saved ids, there's no one true way to do this (though I prefer the setresuid semantics myself).

[jkeenan]

@hvds @Leont there's been no further discussion in this ticket, so I'm self-assigning it for the purpose of closing it within two weeks unless you or someone has a strong objection.

[jkeenan]

@hvds @Leont there's been no further discussion in this ticket, so I'm self-assigning it for the purpose of closing it within two weeks unless you or someone has a strong objection.

Closing as per schedule.