From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Davidlohr Bueso <dave@stgolabs.net>,
Manfred Spraul <manfred@colorfullife.com>,
Markus Elfring <elfring@users.sourceforge.net>,
Yoji <yoji.fujihar.min@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ipc/mqueue.c: change __do_notify() to bypass check_kill_permission()
Date: Sun, 22 Mar 2020 21:29:29 +0100 [thread overview]
Message-ID: <20200322202929.GA1614@redhat.com> (raw)
In-Reply-To: <87lfnsh3tm.fsf@x220.int.ebiederm.org>
On 03/22, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > Commit cc731525f26a ("signal: Remove kernel interal si_code magic")
> > changed the value of SI_FROMUSER(SI_MESGQ), this means that mq_notify()
> > no longer works if the sender doesn't have rights to send a signal.
> >
> > Change __do_notify() to use do_send_sig_info() instead of kill_pid_info()
> > to avoid check_kill_permission().
>
> I totally see why you are doing this. To avoid the permission check,
> and since this process requested the signal it makes sense to bypass the
> permission checks.
And this is what we had before cc731525f26a, so this patch tries to fix
the regression.
> The code needs to make certain that this signal is
> canceled or otherwise won't be sent after an exec.
not sure I understand this part, but see below.
> That said I don't like it. I would really like to remove the signal
> sending interfaces that take a task_struct.
Oh, can we discuss the possible cleanups separately? On top of this fix,
if possible.
> Looking at the code I currently see several places where we have this
> kind of semantic (sending a requested signal to a process from the
> context of another process): do_notify_parent, pdeath_signal, f_setown,
> and mq_notify.
To me they all differ, I am not sure I understand how exactly you want
to unify them...
> Especially with the concerns about being able to send a signal after
> exec, and cause havoc.
...
> Espeically
> with concerns about being able to send signals to a suid process that
> would normally fail I think there is an issue here.
I can easily misread this code, never looked into ipc/mqueue.c before.
But it seems that it is not possible to send a signal after exec, suid
or not,
- sys_mq_open() uses O_CLOEXEC
- mqueue_flush_file() does
if (task_tgid(current) == info->notify_owner)
remove_notification(info);
> At the very least can you add a big fat comment about the semantics
> that userspace expects in this case?
Me? You are kidding ;)
I know absolutely nothing about ipc/mqueue, and when I read this code
or manpage I find the semantics of mq_notify is very strange.
Oleg.
next prev parent reply other threads:[~2020-03-22 20:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-22 11:09 [PATCH] ipc/mqueue.c: change __do_notify() to bypass check_kill_permission() Oleg Nesterov
2020-03-22 14:17 ` Eric W. Biederman
2020-03-22 14:59 ` Eric W. Biederman
2020-03-22 20:29 ` Oleg Nesterov [this message]
2020-03-23 16:47 ` Eric W. Biederman
2020-03-24 2:12 ` Andrew Morton
2020-03-24 2:57 ` Eric W. Biederman
2020-03-24 11:52 ` Oleg Nesterov
2020-03-24 20:08 ` Oleg Nesterov
2020-03-24 10:35 ` Oleg Nesterov
2020-03-24 20:09 ` [PATCH V2] " Oleg Nesterov
2020-03-26 12:54 ` Eric W. Biederman
2020-03-27 19:56 ` [PATCH -mm] ipc-mqueuec-change-__do_notify-to-bypass-check_kill_permission-fix Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200322202929.GA1614@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=ebiederm@xmission.com \
--cc=elfring@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=yoji.fujihar.min@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.