Re: Doku Wiki femail?
Mihai Popescu wrote: > > It is an old less-secure practice ... > > I use to think about security as secure / insecure (not secure). Is it ok > to use grades like less secure, more secure, etc.? Let me provide a better answer. When you use fewer simple ingredients, you can judge the interactions between the the simple components better, and have a more clear understanding that you have achieved your objectives... and not have a pile of curious latent behaviours as well. The crucial behaviour we call "security" really just means the software performs the intended goal only, and cannot be convinced to perform additional unintended behaviours. People are putting random things into chroot, hoping that it works fine. Now people are going to say, surely ksh is not complicated. It needs nothing. If my environment works once in test for my specific test case, it will work the other million times without flaw. I believe that is incompetent delusion. If you don't know precisely what you putting into the mixing bowl and why you shouldn't be making a cake, get a job in sales or something and save us all the grief. Or go ahead, use a bunch of draino and some matchheads, but don't share it.
Re: Doku Wiki femail?
Mihai Popescu wrote: > > It is an old less-secure practice ... > > I use to think about security as secure / insecure (not secure). Is it ok > to use grades like less secure, more secure, etc.? chroot is used to create a really crappy privsep. Worse than duct tape in the sun.
Re: Doku Wiki femail?
> It is an old less-secure practice ... I use to think about security as secure / insecure (not secure). Is it ok to use grades like less secure, more secure, etc.? Thanks.
Re: [PATCH 4/4] script(1): explicitly specify sh -c
On Mon, Jan 03, 2022 at 09:33:19PM +0100, ?? wrote: > On Sun, Jan 02, 2022 at 11:52:49PM +, Jason McIntyre wrote: > > On Sun, Jan 02, 2022 at 11:47:04PM +0100, ?? wrote: > > > On Sun, Jan 02, 2022 at 06:56:37PM +, Jason McIntyre wrote: > > > > On Sat, Jan 01, 2022 at 11:07:49PM +0100, ?? wrote: > > > > > @@ -69,8 +69,8 @@ retaining the prior contents. > > > > > .It Fl c Ar command > > > > > Run > > > > > .Ar command > > > > > +.Pq via Nm sh Fl c Ar command > > > > > instead of an interactive shell. > > > > > > > > or i suppose we could say > > > > > > > > Run > > > > .Nm sh Fl c Ar command , > > > > instead of an interactive shell. > > > Agree, this is much better phrasing, cheers. > > > > > > > > -To run a command with arguments, enclose both in quotes. > > > > why do you want to remove this line? the page is short, and it might > > > > help someone. > > > Because the value for -c is a *shell script*, not a command ??? > > > > i don;t follow. you can run: > > > > $ script -c ls > > > > i.e. a command, not a shell script/ > No, "ls" is definitely a shell script. It forks, execps ["ls"], waits, > then exits with WEXITSTATUS() or 128+WTERMSIG(). > In many ways this is not that different than if you'd ran > `script -c exec\ ls`, in which case the shell would just execp ["ls"]. > > > > I didn't think to change it out ??? it's much more confusing to have this > > > include mention of arguments when, well, they aren't: this reads as-if > > > script -c 'echo a || b' > > > ran ["echo", "a", "||", "b"] ??? you can see issue here. > > why would you think this? the text just explains that if you have > > command+args you should quote it. > Which means absolutely nothing, because script -c doesn't take a command > or arguments ??? it takes a shell program as the argument, which either > starts at the next byte, if non-NUL, or is the entire next argument > (XBD 12.1.2.a). > > Maybe I'm too hopeful in assuming the baseline of understanding how > shell tokenisation works in the user? > > > > -To run a command with arguments, enclose both in quotes. > > > +Scripts longer than just the name of a command need to be quoted, > > > +and are subject to re-expansion. > > that's a horrible sentence. i don;t see any improvement. > Sure. Given this and Matthew's post, I've opted to leave both the Ar > name and sentence as-is. > > Scissor-patch below. > committed, thanks. > Also, unrelatedly, does your MUA just completely give up when decoding > UTF-8 and convert each byte to a "?", or? > yes. i do not have any locale stuff set. jmc > -- >8 -- > Subject: [PATCH v3 4/4] script(1): explicitly specify sh -c > > The original wording is weird and doesn't explicitly say that it does > sh -c, which is the fundamental point ??? spell it out directly > --- > usr.bin/script/script.1 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 > index 28783961a..857b387b6 100644 > --- a/usr.bin/script/script.1 > +++ b/usr.bin/script/script.1 > @@ -68,7 +68,7 @@ or > retaining the prior contents. > .It Fl c Ar command > Run > -.Ar command > +.Nm sh Fl c Ar command > instead of an interactive shell. > To run a command with arguments, enclose both in quotes. > .El > -- > 2.30.2 >
Re: Doku Wiki femail?
Thomas Bohl wrote:
> Hello,
>
> > After several tries, i think the problem is the interpretation, in
> > Universal Language; usually used in OBSD, it could be:
> > Write this
> > Do this
> > But, in this case; there are not commands!
> > Please, let me ask you, How to add /bin/sh to the chroot?
> > How to add host? resolv.conf? and femail.conf?
> > How to create /var/www/etc/other files?
> > From where do i have to create every thing?
>
> That is what I always do for httpd chroot:
>
> # mkdir -p /var/www/usr/local/share/icu/
> # mkdir -p /var/www/etc/ssl/
> # cp -r /usr/local/share/icu/* /var/www/usr/local/share/icu/
> # cp /etc/ssl/openssl.cnf /var/www/etc/ssl/
> # cp /etc/ssl/cert.pem /var/www/etc/ssl/
> # cp /etc/{hosts,resolv.conf,localtime} /var/www/etc/
> # chown -R root:daemon /var/www/etc/ssl
> # chown -R root:daemon /var/www/usr/
>
>
> I haven't had the need for /bin/sh in chroot, so this is untested. But
> judging by
> $ ldd /bin/sh
>
> # mkdir /var/www/bin/
> # cp /bin/sh /var/www/bin/
>
> should be it.
No. Programs don't run in a vacuum. They need various things in
the filesystem.
I do not think we should document what those things are, because
the practice of running binaries inside such chroot spaces is highly
discouraged. It is an old less-secure practice for a less-secure
era and we don't need to help people re-create it. When people
believe they really need to do so, we provide the tools they need to
learn what is required: ktrace & kdump. And I really mean they need
to learn to use those tools. If they don't understand the low-level
system behaviours that happen, then why the HELL do they think they can
use chroot safely?
Re: [PATCH 4/4] script(1): explicitly specify sh -c
On Sun, Jan 02, 2022 at 11:52:49PM +, Jason McIntyre wrote: > On Sun, Jan 02, 2022 at 11:47:04PM +0100, ?? wrote: > > On Sun, Jan 02, 2022 at 06:56:37PM +, Jason McIntyre wrote: > > > On Sat, Jan 01, 2022 at 11:07:49PM +0100, ?? wrote: > > > > @@ -69,8 +69,8 @@ retaining the prior contents. > > > > .It Fl c Ar command > > > > Run > > > > .Ar command > > > > +.Pq via Nm sh Fl c Ar command > > > > instead of an interactive shell. > > > > > > or i suppose we could say > > > > > > Run > > > .Nm sh Fl c Ar command , > > > instead of an interactive shell. > > Agree, this is much better phrasing, cheers. > > > > > > -To run a command with arguments, enclose both in quotes. > > > why do you want to remove this line? the page is short, and it might > > > help someone. > > Because the value for -c is a *shell script*, not a command ??? > > i don;t follow. you can run: > > $ script -c ls > > i.e. a command, not a shell script/ No, "ls" is definitely a shell script. It forks, execps ["ls"], waits, then exits with WEXITSTATUS() or 128+WTERMSIG(). In many ways this is not that different than if you'd ran `script -c exec\ ls`, in which case the shell would just execp ["ls"]. > > I didn't think to change it out ??? it's much more confusing to have this > > include mention of arguments when, well, they aren't: this reads as-if > > script -c 'echo a || b' > > ran ["echo", "a", "||", "b"] ??? you can see issue here. > why would you think this? the text just explains that if you have > command+args you should quote it. Which means absolutely nothing, because script -c doesn't take a command or arguments ‒ it takes a shell program as the argument, which either starts at the next byte, if non-NUL, or is the entire next argument (XBD 12.1.2.a). Maybe I'm too hopeful in assuming the baseline of understanding how shell tokenisation works in the user? > > -To run a command with arguments, enclose both in quotes. > > +Scripts longer than just the name of a command need to be quoted, > > +and are subject to re-expansion. > that's a horrible sentence. i don;t see any improvement. Sure. Given this and Matthew's post, I've opted to leave both the Ar name and sentence as-is. Scissor-patch below. Also, unrelatedly, does your MUA just completely give up when decoding UTF-8 and convert each byte to a "?", or? -- >8 -- Subject: [PATCH v3 4/4] script(1): explicitly specify sh -c The original wording is weird and doesn't explicitly say that it does sh -c, which is the fundamental point ‒ spell it out directly --- usr.bin/script/script.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 index 28783961a..857b387b6 100644 --- a/usr.bin/script/script.1 +++ b/usr.bin/script/script.1 @@ -68,7 +68,7 @@ or retaining the prior contents. .It Fl c Ar command Run -.Ar command +.Nm sh Fl c Ar command instead of an interactive shell. To run a command with arguments, enclose both in quotes. .El -- 2.30.2 signature.asc Description: PGP signature
Re: Doku Wiki femail?
> On 2022-01-03, latin...@vcn.bc.ca wrote: >> Hello >> >> i did an installation of dokuwiki over OBSD 7.0, but i am not bring able >> to configure femail! >> >> i am following this: >> >>| Running femail-chroot on OpenBSD >> +--- >> >> Setup with httpd from OpenBSD base system >>= >> By default, femail will use `localhost' for smtphost. >> httpd(8) inside the chroot(2) will NOT be able to use the system >> /etc/hosts or /etc/resolv.conf. One will need to populate >> /var/www/etc/hosts >> and/or /var/www/etc/resolv.conf in the chroot(2) environment. >> >> Additionally, one may create a custom femail.conf; see femail(8). >> >> If you're using femail with PHP inside a chroot jail, be aware that >> PHP's built-in "mail" function uses popen(), which requires /bin/sh. >> >> I have tried different ways without success. >> >> Can somebody help please? dokuwiki works correctly in general, exept >> femail. >> >> Please respond to the list. >> >> >> > > dokuwiki uses PHP's build-in "mail" function, so you need /bin/sh in the > chroot. > > -- > Please keep replies on the mailing list. > Thanks Stuart After several tries, i think the problem is the interpretation, in Universal Language; usually used in OBSD, it could be: Write this Do this But, in this case; there are not commands! Please, let me ask you, How to add /bin/sh to the chroot? How to add host? resolv.conf? and femail.conf? How to create /var/www/etc/other files? >From where do i have to create every thing? I think i am completely lost! Thanks for your attention.
Re: httpd HTTP/2 and HTTP/3 support
On Fri, Dec 31, 2021 at 09:36:54AM -, Stuart Henderson wrote: > On 2021-12-31, Georg Pfuetzenreuter wrote: > > Hi, > > I searched but couldn't find any recent threads. > > Does httpd support HTTP/2? > > No. > > > Is support for the upcoming HTTP/3 planned? > > guessing but I think this would also be "no". It is indeed not. HTTP/3 is "just" HTTP/2 over QUIC. Implementing reliable communication over UDP in userland is a lot of work and it is rather complicated. On top it is a violation of the OSI stack and the socket(2) API. And then it needs to be reimplemented for every application that wants to use it. -- :wq Claudio
Re: pkg_add issues
On Mon, Jan 03, 2022 at 12:21:17PM -, Stuart Henderson wrote: > On 2022-01-02, Jon Fineman wrote: > > I am in New Jersey. Is there a way for me to tell what the cdn was > > pointing to to help find the slow/sick server? > > It's shown in HTTP response headers from cdn. Almost certainly > it was pointing at a machine which only serves the cdn and you cannot > access directly. pkg_add explicitly shows it in the first file it retrieves. For various reasons (consistency), we don't do cdn round-robin on each package. The Redirect from the first connection will be automatically re-used in the subsequent connections.
Re: pkg_add issues
On 2022-01-02, Jon Fineman wrote: > I am in New Jersey. Is there a way for me to tell what the cdn was > pointing to to help find the slow/sick server? It's shown in HTTP response headers from cdn. Almost certainly it was pointing at a machine which only serves the cdn and you cannot access directly. -- Please keep replies on the mailing list.
Re: Doku Wiki femail?
On 2022-01-03, latin...@vcn.bc.ca wrote: > Hello > > i did an installation of dokuwiki over OBSD 7.0, but i am not bring able > to configure femail! > > i am following this: > >| Running femail-chroot on OpenBSD > +--- > > Setup with httpd from OpenBSD base system >= > By default, femail will use `localhost' for smtphost. > httpd(8) inside the chroot(2) will NOT be able to use the system > /etc/hosts or /etc/resolv.conf. One will need to populate /var/www/etc/hosts > and/or /var/www/etc/resolv.conf in the chroot(2) environment. > > Additionally, one may create a custom femail.conf; see femail(8). > > If you're using femail with PHP inside a chroot jail, be aware that > PHP's built-in "mail" function uses popen(), which requires /bin/sh. > > I have tried different ways without success. > > Can somebody help please? dokuwiki works correctly in general, exept femail. > > Please respond to the list. > > > dokuwiki uses PHP's build-in "mail" function, so you need /bin/sh in the chroot. -- Please keep replies on the mailing list.
