public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Sergey Bugaev <bugaevc@gmail.com>
To: Samuel Thibault <samuel.thibault@gnu.org>
Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org
Subject: Re: [PATCH v2 2/4] hurd: Implement MSG_CMSG_CLOEXEC
Date: Tue, 25 Apr 2023 00:35:58 +0300	[thread overview]
Message-ID: <CAN9u=HdynAzBvLdzbxkc=gUxNuf12M2PSmiGvpGOogn6S+hsaw@mail.gmail.com> (raw)
In-Reply-To: <20230424211009.3dbv745qz36vmkpi@begin>

On Tue, Apr 25, 2023 at 12:10 AM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> Applied, thanks!

Thank you -- but I see you changed it to say "fds[j] | fd_flags".

For one thing it would be nice of you to indicate that this was your
change, not mine, because as things are it looks like I wrote that,
but I didn't. Linux docs (I was about to write "kernel docs", heh)
suggest this pattern:

> it is recommended that you add a line between the last
> Signed-off-by header and yours, indicating the nature of your
> changes. While there is nothing mandatory about this, it seems like
> prepending the description with your mail and/or name, all enclosed
> in square brackets, is noticeable enough to make it obvious that you
> are responsible for last-minute changes. Example :
>
> Signed-off-by: Random J Developer <random@developer.example.org>
> [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
> Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>

But on the technical side of things, I don't think we should take
whatever integer arrives in the message and use it as flags. We never
check it for sanity; who knows what might be there; the fd management
subsystem is not generally written with the assumption that 'flags'
might be attacker-controlled/malicious. I don't see how anything
actually bad could happen in this case, but it could specify O_CLOEXEC
and/or O_IGNORE_CTTY when we don't want them, for instance.

Sergey

  reply	other threads:[~2023-04-24 21:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-23 16:05 [PATCH v2 1/4] hurd: Don't pass FD_CLOEXEC in CMSG_DATA Sergey Bugaev
2023-04-23 16:05 ` [PATCH v2 2/4] hurd: Implement MSG_CMSG_CLOEXEC Sergey Bugaev
2023-04-24 21:10   ` Samuel Thibault
2023-04-24 21:35     ` Sergey Bugaev [this message]
2023-04-24 22:18       ` Samuel Thibault
2023-04-23 16:05 ` [PATCH v2 3/4] hurd: Only deallocate addrport when it's valid Sergey Bugaev
2023-04-24 20:44   ` Samuel Thibault
2023-04-23 16:05 ` [PATCH v2 4/4] socket: Add a test for MSG_CMSG_CLOEXEC Sergey Bugaev
2023-04-24 22:21   ` Samuel Thibault
2023-04-24 21:01 ` [PATCH v2 1/4] hurd: Don't pass FD_CLOEXEC in CMSG_DATA Samuel Thibault
2023-04-24 21:13   ` Sergey Bugaev

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='CAN9u=HdynAzBvLdzbxkc=gUxNuf12M2PSmiGvpGOogn6S+hsaw@mail.gmail.com' \
    --to=bugaevc@gmail.com \
    --cc=bug-hurd@gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=samuel.thibault@gnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).