From: Jacob Moody <email@example.com> To: firstname.lastname@example.org Subject: Re: [9front] [PATCH] kernel: disallow executing from #| or #d Date: Tue, 10 May 2022 10:34:28 -0600 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <77567FF86B34A592067F8FA1ADD7F3C6@eigenstate.org> On 5/10/22 08:40, firstname.lastname@example.org wrote: > I think all files should be the same, as much as > they can be -- we shouldn't necessarily need to > care if we have a pipe or not. > In general I think I agree, but I would argue that its not the exec code that is special casing itself from using these files. The devices are electing themselves to say that execution is not a supported operation on the files they serve, but perhaps that is just semantics. I want to explain more of why I think this is not ideal. I am approaching this from the question "what capabilities does a sharp device give you?". And I think it is a bit surprising to say access to #| or #d also gives a process the ability to execute arbitrary code stashed in to one end of a pipe. I can imagine such a case of building a namespace where the binaries exposed are hand picked, and I think its reasonable to want to restrict what binaries can be executed while also allowing programs to use dup() and pipe(). But perhaps my approach here is wrong, it could be that it is inherently misleading to think about a programs capabilities in terms of what kernel devices the program has access to. moody
next prev parent reply other threads:[~2022-05-10 16:44 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-10 6:40 Jacob Moody 2022-05-10 14:40 ` ori 2022-05-10 16:34 ` Jacob Moody [this message] 2022-05-10 19:59 ` Amavect 2022-05-10 22:47 ` Jacob Moody 2022-05-11 4:21 ` Amavect 2022-05-11 6:31 ` Jacob Moody 2022-05-11 16:32 ` Amavect 2022-05-11 16:50 ` Jacob Moody 2022-05-15 2:43 ` Amavect 2022-05-15 15:26 ` Amavect 2022-05-15 16:28 ` Jacob Moody 2022-05-10 20:52 ` [9front] " Anthony Martin
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [9front] [PATCH] kernel: disallow executing from #| or #d' \ /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
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 NNTP newsgroup(s).