On 8/30/24 4:11 AM, Stuart Henderson wrote:
> On 2024/08/29 23:07, A Tammy wrote:
>> On 8/19/24 3:24 PM, Chaz Kettleson wrote:
>>> On Mon, Aug 19, 2024 at 03:48:20PM GMT, Omar Polo wrote:
>>>> On 2024/08/17 16:28:35 +0100, Stuart Henderson <stu@spacehopper.org> wrote:
>>>>> ok
>>>> Imported
>>>>
>>>> Thank you,
>>>>
>>>> Omar Polo
>>>>
>>> Thanks everyone! Great feedback.
>>>
>>> Below are patches for pledge/unveil for feedback/discussion.
>>>
>>> Here is the approach that was taken:
>>>
>>> - Start with minimal set of promises that did not crash and from review
>>> stdio
>>> rpath - hopm config file, firedns config
>>> wpath - pid file, log file, scanlog file
>>> cpath - pid file, log file, scanlog file
>>> inet
>>> dns
>>> proc - fork (maybe we can remove fork and rc_bg?)
>>> exec - execv on restart
>>> unveil
>>> - Initially unveil nothing
>>> - Remove unneeded chdir (locations are no longer relative)
>>> - Unveil only what is needed if it's needed before main loop
>>> LOGFILE, wc
>>> CONFFILE, r
>>> SCANLOG, wc (only if the option is enabled)
>>> HOPM_BINPATH, x (for execv on restart)
>>> - Reduce promises before main loop
>>> stdio
>>> inet
>>> dns
>>> exec
>>>
>> committed, thanks!
> That feels premature
I've reverted the patch for now, with a revbump.
> The initial pledge("stdio rpath wpath cpath inet dns proc exec unveil"
> and unveil("/", "") at the start of main are not how pledge/unveil are
> normally used
>
> What reason is there for removing the chdir?
>
> Why go to the trouble of setting up dynamic unveils when filesystem
> access is disabled with pledge("stdio inet dns exec" anyway?
>
> Is there any analysis to show that it doesn't use any syscalls which
> it has pledged not to use other than "it didn't crash"? I think nm -s
> and looking for the library functions used is a good start at that
"it didn't crash" and it was able to make a connection to an irc server
was my test method.
@chaz I think it might be better to get these patches upstreamed to make
sure they are working correctly in all setups.
>
> Also this was committed without bumping REVISION.
>
No comments:
Post a Comment