This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 5/7] linux: Remove SIGCANCEL/SIGSETXID handling on sigprocmask
On 12/12/2019 16:29, Zack Weinberg wrote:
> On Thu, Dec 12, 2019 at 2:05 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 12/12/2019 14:59, Zack Weinberg wrote:
>>> On Thu, Dec 12, 2019 at 8:44 AM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>> On 12/12/2019 10:12, Florian Weimer wrote:
>>>>> * Adhemerval Zanella:
>>>>>
>>>>>> On 12/12/2019 09:54, Florian Weimer wrote:
>>>>>>> * Adhemerval Zanella:
>>>>>>>
>>>>>>>> The sigfillset already does it, and this is the canonical way to operate
>>>>>>>> on sigset_t. The only way to actually broke this assumption is if caller
>>>>>>>> initialize sigset with memset or something similar, i.e, bypassing glibc
>>>>>>>> (and again this is not a valid construction).
>>>
>>> I think it would be appropriate for us to guarantee that `memset(s, 0,
>>> sizeof(sigset_t))` has the same effect as `sigemptyset(s)`, because I
>>> bet there is real code that does that, probably without realizing it's
>>> technically wrong (e.g. by using memset to wipe an entire struct
>>> sigaction and then not bothering to do a separate sigemptyset on
>>> sa_mask, or by statically allocating a sigset_t and assuming that
>>> zero-initialization will produce the same effect as sigemptyset).
>>>
>>> But that argument doesn't apply to `memset(s, 0xFF, sizeof(sigset_t))`.
>>
>> In this case we will to either keep the current semantic or remove any
>> filter in sigprocmark, sigemptyset, sigfillset, sigaddset, and sigdelset.
>
> I think I didn't explain myself clearly enough; I am _not_ pointing
> out a problem with your proposed patch. We don't support blocking
> SIGSETXID and SIGCANCEL, but we don't care if someone tries to unblock
> them, because they never get blocked in the first place. So
> `memset(s, 0, sizeof(sigset_t))` currently _does_ have the same effect
> as `sigemptyset(s)` and your patch wouldn't change that. And
> `memset(s, 0xFF, sizeof(sigset_t))` currently _doesn't_ have the same
> effect as `sigfillset(s)` and, again, your patch wouldn't change that.
> And I think we need to support `memset(s, 0, sizeof(sigset_t))` but
> not `memset(s, 0xFF, sizeof(sigset_t))`.
Yeah I got you what you meant and my point of withdrew this patch is
sigprocmask should indeed filter against unwarranted changes in sigset_t
(by tricks like casting to a different type or memset 0xff). And that's
why maybe a better option is to fail and alert the user that trying to
block reserved signals are not allowed (by returning EINVAL).