From: Klemens Nanni <kn@openbsd.org>
On OpenBSD, pledge(2) is used regardless of restricted mode.
While it is true that restricted mode applies even tighter
pledges and also limits filesystem access to specific directories,
I argue that such (OS specific) implementation detail should not
be documented.
The current wording is misleading as it implies that no pledge is
done without restricted mode; furthermore, both pledge and unveil
work transparently, i.e. it is a bug if their usage would result
in a change of behaviour of the program.
---
catgirl.1 | 7 -------
1 file changed, 7 deletions(-)
diff --git a/catgirl.1 b/catgirl.1
index f0dddfe..f14ba3a 100644
--- a/catgirl.1
+++ b/catgirl.1
@@ -165,13 +165,6 @@ and
commands,
as well as viewing this manual with
.Ic /help .
-On
-.Ox ,
-restrict system operations
-and filesystem access with
-.Xr pledge 2
-and
-.Xr unveil 2 .
.
.It Fl S Ar host , Cm bind = Ar host
Bind to source address
--
2.30.0
> On Jan 23, 2021, at 05:32, Klemens Nanni <klemens@posteo.de> wrote:
>
> On OpenBSD, pledge(2) is used regardless of restricted mode.
> While it is true that restricted mode applies even tighter
> pledges and also limits filesystem access to specific directories,
> I argue that such (OS specific) implementation detail should not
> be documented.
>
> The current wording is misleading as it implies that no pledge is
> done without restricted mode; furthermore, both pledge and unveil
> work transparently, i.e. it is a bug if their usage would result
> in a change of behaviour of the program.
It’s true the wording is misleading, but I feel like this should
be documented somewhere — this is not OpenBSD software so I don’t
think there would be any expectation that it actually uses pledge(2)
and unveil(2). And on the other hand, I don’t want to imply that
this option makes process execution impossible on other platforms,
since elsewhere the commands are simply disabled but a vulnerability
or oversight could still make it possible.
On Sat, Jan 23, 2021 at 12:07:50PM -0500, June Bug wrote:
> It’s true the wording is misleading, but I feel like this should
> be documented somewhere — this is not OpenBSD software so I don’t
> think there would be any expectation that it actually uses pledge(2)
> and unveil(2). And on the other hand, I don’t want to imply that
> this option makes process execution impossible on other platforms,
> since elsewhere the commands are simply disabled but a vulnerability
> or oversight could still make it possible.
Agreed, one should not expect pledge support. However, as you concluded,
pledge is an OS specific implementation detail providing an OS specific
safety feature.
Imho, the manual should document catgirl's intrinsic behaviour and only
that -- say catgirl gains Capsium support, would you then amend the
manual to reflect that?
Afterall mentioning it does not do any harm, I just this it is unwarranted
and/or the wrong place to do so.
In case you want to keep the mention, what about this diff to at least get
rid of the ambiguity? That I consider a documentation bug of its own since
`-R's text implies that pledge is not used without it.
(This somewhat shows the problem I have with documenting it: mentioning
the default to pledge in `-R's text seems off, but DESCRIPTION does not
seem right, either; and I guess we don't want to add it under
IMPLEMENTATION NOTES.
I failed to come up with a diff that is a) clear enough and b) does not
duplicate information that ought to be found in pledge(2) and unveil(2).)
You see, pledge is done by default and `-R' further tightens it; unveil
however is not done by default and `-R' activates it -- that rather
important detail is missing in HEAD *and* this new diff...
-- >8 --
Subject: [PATCH] manual: Try to be clear about default pledge
---
catgirl.1 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/catgirl.1 b/catgirl.1
index f0dddfe..670f615 100644
--- a/catgirl.1
+++ b/catgirl.1
@@ -167,8 +167,8 @@ as well as viewing this manual with
.Ic /help .
On
.Ox ,
-restrict system operations
-and filesystem access with
+further reduce the set of system calls and
+filesystem access allowed by default with
.Xr pledge 2
and
.Xr unveil 2 .
--
2.30.0
> On Jan 25, 2021, at 07:59, Klemens Nanni <kn@openbsd.org> wrote:
>
> On Sat, Jan 23, 2021 at 12:07:50PM -0500, June Bug wrote:
>> It’s true the wording is misleading, but I feel like this should
>> be documented somewhere — this is not OpenBSD software so I don’t
>> think there would be any expectation that it actually uses pledge(2)
>> and unveil(2). And on the other hand, I don’t want to imply that
>> this option makes process execution impossible on other platforms,
>> since elsewhere the commands are simply disabled but a vulnerability
>> or oversight could still make it possible.
> Agreed, one should not expect pledge support. However, as you concluded,
> pledge is an OS specific implementation detail providing an OS specific
> safety feature.
>
> Imho, the manual should document catgirl's intrinsic behaviour and only
> that -- say catgirl gains Capsium support, would you then amend the
> manual to reflect that?
>
> Afterall mentioning it does not do any harm, I just this it is unwarranted
> and/or the wrong place to do so.
>
> In case you want to keep the mention, what about this diff to at least get
> rid of the ambiguity? That I consider a documentation bug of its own since
> `-R's text implies that pledge is not used without it.
>
> (This somewhat shows the problem I have with documenting it: mentioning
> the default to pledge in `-R's text seems off, but DESCRIPTION does not
> seem right, either; and I guess we don't want to add it under
> IMPLEMENTATION NOTES.
I think I will move this to the README near where platform support
is listed. There is room there to be more clear about the behaviour.
> I failed to come up with a diff that is a) clear enough and b) does not
> duplicate information that ought to be found in pledge(2) and unveil(2).)
>
> You see, pledge is done by default and `-R' further tightens it; unveil
> however is not done by default and `-R' activates it -- that rather
> important detail is missing in HEAD *and* this new diff...