Re: FreeBSD daemon(8)-like command for OpenBSD

[KatolaZ]

On Fri, Jan 31, 2020 at 06:39:04PM +, Moisés Simón wrote:
> Sorry to hijack,
> 
> Do you know of any basic guide for this?
> 
> I have done a syslog normalizer daemon which calls pledge(), unveil() and 
> redirects std{out,err} and forks to search and normalize the logs.
> 
> I'm not professional programmer so I'm doing my best and want to learn as 
> much as I can.
> 
> Thank you

I guess the best guide is the code itself :) You can have a look at
/usr/src/lib/libc/gen/daemon.c, where the libc function daemon(3) is
defined. You can also see a simple and complete example in the code of
something like tftpd at /usr/src/usr.sbin/tftpd/tftpd.c

that code uses a local clone of daemon(3) (that is called rdaemon),
but the logic is exactly the same, and it's a full working example
with chdir(2) (or chroot(2)), privilege drop, fork(2), setsid(2),
close stdin/stdout/stderr, and pledge(2) before the daemon starts to
do its things.

Ingo has already provided pointers to excellent resources about the
general concepts and the typical organisation and implementation of
processes in Unix.

HTH

Re: FreeBSD daemon(8)-like command for OpenBSD

[Ingo Schwarze]

Hi Patrick,

Patrick Kristiansen wrote on Fri, Jan 31, 2020 at 10:17:35AM +0100:

> Trying to learn some valuable lessons from our interaction, could you
> give some examples of what you mean by 'simpler approach' in this
> context?

Three examples:

  https://learnbchs.org/

  https://man.openbsd.org/man.cgi  --
  this one written from scratch without any framework

  https://man.openbsd.org/bgplg

> Do you mostly do systems programming?

  https://mandoc.bsd.lv/press.html

and also see my various CV abstracts for BSDCan.

Yours,
  Ingo

Re: FreeBSD daemon(8)-like command for OpenBSD

[Ingo Schwarze]

Hi Andrew,

Andrew Easton wrote on Fri, Jan 31, 2020 at 11:39:45AM +0100:

> In the spirit of not demanding to much time from my contemporaries I
> am especially greatful for pointers to conceptual documentation

This is the closest thing, i guess:

  https://www.openbsd.org/events.html

In general, to save time, the OpenBSD projects maintains only concise
reference documentation, not introductory documents or tutorials.

> and to implementation documentation.

For the kernel in general, see section 9 in man(1).

For userland programs, implementation documentation does not exist
in general, though there are are a few rare exceptions, see for
example the manual pages "For programmers:" listed
on https://mandoc.bsd.lv/ and some very rare text files scattered
around the source tree - but be careful, some of these can be
seriously outdated.

In general, our recommendation is RTFS (read the fantastic source
code).

Specifically, i'm not convinced that implementation documentation
exists for pledge(2) or unveil(2), but i may have missed something.

> [[ I have the suspicion that being a good programmer crucially depends
> on having conceptual understanding. Maybe it also depends on practice.]]

Many of us develop their conceptual understanding from reading source
code and from practice.

> Concretely:
> Just to start off easy, how can I find conceptual documentation on
> what an operating system "process" is in OpenBSD

While various details about how the kernel manages processes are no
doubt OS-specific, the conceptual ideas are probably more or less
common to all Unix implementations.  For the basics, standard text
books may be useful, as found on https://www.openbsd.org/books.html ,
for example Kirk's classic "Design and Implementation of the 4.4BSD
Operating System".

> and how deeply a libc
> is tied into that by design? As far as I am aware a process has the
> "current working directory" associated with it, in order to be able to
> resolve relative paths and is also where "environment variables" are
> stored.  These remind me of dynamic bindings, at least in spirit. I am
> only aware of plain C having lexical bindings, in contrast to this.

For such details, our recommendation generally is "read the source".

Start from the section 2 and 3 manual pages of the functions you
are interested in.  Then, if you need more details about how it's
implemented, read the libc code.  Then, if you need even more
details, read the code handling the syscalls in the kernel, of
those syscalls that are used in the libc implementation.

As opposed to the mess you are maybe used to from glibc, OpenBSD
code is generally very concise and readable.

Yours,
  Ingo

Re: FreeBSD daemon(8)-like command for OpenBSD

[Luke Call]

The list might not like this but:
Under your circumstances, I would collect the various ideas in this
thread (including scripting possibly with nohup and/or bash's disown), 
the "pgrep || " idea somebody wrote, and whatever else is
useful from the thread, and just make it work with careful testing of
different failure scenarios.  I found that when writing a cron job I had
to test very carefully if different things failed about it, before I
actually got it right.  Logs can be done with things like 
   > somefile.log 2>&1
...or variations, and if you then check it occasionally to see that it
is working, learn, move on, things can probably work out.

Then if it is ever rewritten in a way that allows doing the things Ingo
suggests, use his suggestions.  In the meantime, isolate it well to
prevent security breaches from affecting other things (ie, considering
what could be affected if/when it is compromised, make sure those other
things are minimized).

Sometimes the cost/benefit realities (or employers) force choices upon us.

-- 
Please pray for our country(ies) and leaders, at this important time.
More on this and other topics (a simple site w/o sales):
http://lukecall.net  (updated 2020-01-23)


On 01-30 21:05, Patrick Kristiansen wrote:
> Hi Ingo,
> 
> On Thu, Jan 30, 2020, at 18:35, Ingo Schwarze wrote:
> > Hi Patrick,
> > 
> > Patrick Kristiansen wrote on Tue, Jan 28, 2020 at 09:29:20AM +0100:
> > 
> > > But another use for daemon(8) is for its ability to detach the child
> > > process from the controlling terminal and furthermore redirect its
> > > stdout/stderr to syslog. Is there some mechanism to do that from the
> > > shell? Perhaps a combination of nohup and starting a background job?
> > 
> > That doesn't strike me as a particularly bright idea either.
> >
> > Properly starting up a daemon process requires several steps, often
> > involving unveil(2), pledge(2), chroot(2), prviledge dropping,
> > sometimes fork+exec for privilege separation, and so on. Typically,
> > these steps need to be intermixed in exactly the right order with
> > option parsing, environment parsing, parsing of configuration files
> > and various kinds of initialization.
> 
> The process I need to run is written in Clojure and thus runs on the
> Java Virtual Machine. Do you have any suggestions on how to best go
> about making it "daemon-like"? I am not sure that I can call unveil(2),
> pledge(2) and chroot(2) from Clojure without some strange sorcery. I
> read in some blog post, that the way to detach from the controlling
> terminal is by closing stdin, stdout and stderr, which I admittedly
> haven't tried.
> 
> > Writing wrappers usually just doesn't work, and it seems doubtful to
> > me whether daemon(8) is up to what is usually needed.
> 
> If I were writing my program in C, I could fairly easily call daemon(3),
> I guess, but I am not. I am starting to think that tmux(1) would be the
> easiest way to go about it on OpenBSD... but it feels wrong.
> 
> Best regards,
> Patrick
> 

Re: FreeBSD daemon(8)-like command for OpenBSD

[Kevin Chadwick]

On 2020-01-31 12:16, KatolaZ wrote:
> For instance, golang has had native support
> for pledge(2) and unveil(2) for a while now.

The semantics are a little different to C unveil but it certainly works and
bundled by default in the golang.org/x. Not sure the documentation is great.

It's a little ironic that whilst golangs smallest binary (ignoring tinygo) is >
2 megabytes preventing generic use. One of the main incentives for it's initial
development was to have something somewhat like C whilst avoiding compiling
unused dependencies and speedup build times. It has found a good place between C
and the montrosity of java and I expect will replace java slowly but likely not
C. Unless unix dies from the systemd treatment (I'm confident it won't in 
OpenBSD)

Re: FreeBSD daemon(8)-like command for OpenBSD

[KatolaZ]

On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote:

[cut]

> 
> I would like to get more information about doing application programming
> for an OS like OpenBSD. I understand that if you program your
> applications in C, you have readily available pledge/unveil, etc. But
> many applications are written in higher-level languages, and in my case
> at least, it seems to be nearly impossible to write a secure application
> without changing to C or some other language that can easily use
> OpenBSD's system calls. And for a mediocre programmer, or just an
> inexperienced one, it exposes you to a whole host of other problems that
> can lead to worse security and quality.
>

Some "high-level" languages have support for some of the
OpenBSD-specific syscalls. For instance, golang has had native support
for pledge(2) and unveil(2) for a while now.

I don't know if the source is authoritative and I am not related to
the author in any way, but there is also a list of which languages
support those syscalls at:

  https://gist.github.com/ligurio/f6114bd1df371047dd80ea9b8a55c104

note that in some cases the support is available from third-parties
modules.

HTH

Re: FreeBSD daemon(8)-like command for OpenBSD

[Janne Johansson]

Den fre 31 jan. 2020 kl 11:48 skrev Andrew Easton :

> On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote:
> > On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote:
> > > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen <
> patr...@tamstrup.dk>:
> > > >  > Properly starting up a daemon process requires several steps,
> > > >  > often involving unveil(2), pledge(2), chroot(2), prviledge
> > > >  > dropping, sometimes fork+exec for privilege separation, and so on
> > > >
> > > >  The process I need to run is written in Clojure and thus runs on the
> > > >  Java Virtual Machine. Do you have any suggestions on how to best go
> > > >  about making it "daemon-like"? I am not sure that I can call
> unveil(2),
> > > >  pledge(2) and chroot(2) from Clojure without some strange sorcery.
>
>
For the record, I am also interested in information on how pledge(2) and
> unveil(2) would interact with a "higher level language".


man OpenBSD::Pledge will show how you call pledge from perl (if you accept
that as a higher level language in this case), and it works mostly because
perl will not silently have tons of secret underlying operations so that
when
you ask perl to concatenate two strings, it will not open sockets and pipe
them to itself in order to do that, or write them to $TEMPDIR or some other
possible construct in order to make a simple operation suddenly require
file system access or socket binding capacity. The more weird (or generic)
your runtime is, the less chances will you get to be able to say "from now
on, I will not open any more files, sockets or call reboot()" because the
runtime may just do one of those, when garbage collecting or something.



> I would also
> be happy to learn more about how they interact with assembly.
>

I'm sure they interact equally well as with C, given that the C program that
calls pledge/unveil at that time is assembler.


> Concretely:
> Just to start off easy, how can I find conceptual documentation on
> what an operating system "process" is in OpenBSD and how deeply a libc
> is tied into that by design? As far as I am aware a process has the
>

libc isn't all that tied to a process, it's just that libc contains some
very neat
and useful functions (like wrapping calloc() over malloc()/mmap() so the
kernel
only exposes one single way for a process to allocate memory, but libc can
still
implement realloc(), calloc() and so on for you, using normal code and the
give-me-some-pages-of-RAM syscall.


> "current working directory" associated with it, in order to be able to
> resolve relative paths and is also where "environment variables" are
> stored.


Well, you can still reach the environment without libc, but libc makes it
easier for you, just like with the something*alloc() routines.


>
> (I am also still fuzzy on how intertwined an operating system and a CPU
> are. From my superficial understanding, e.g.  the operating system has
> to be aware of the MMU.


I think that is a completely separate dimension, but yes, given that the OS
controls and commands the MMU to do various things, it most certainly
is "aware" of it.

-- 
May the most significant bit of your life be positive.

Re: FreeBSD daemon(8)-like command for OpenBSD

[Andrew Easton]

On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote:
> On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote:
> > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen 
> > :
> > >  > Properly starting up a daemon process requires several steps,
> > >  > often involving unveil(2), pledge(2), chroot(2), prviledge
> > >  > dropping, sometimes fork+exec for privilege separation, and so on
> > > 
> > >  The process I need to run is written in Clojure and thus runs on the
> > >  Java Virtual Machine. Do you have any suggestions on how to best go
> > >  about making it "daemon-like"? I am not sure that I can call unveil(2),
> > >  pledge(2) and chroot(2) from Clojure without some strange sorcery.
> > 
> > So not related to only Clojure but rather on runtimes that are large
> > and unwieldy, this seems to be exactly why plegde() and unveil() came
> > into being in the first place, after seeing things that needs to do
> > certain privileged operations at some early point, but because of
> > design/runtime/hard-to-pledge or whatever has to run with the sum of
> > all privileges, all capabilities at all times and at the same time
> > being exposed to potential hostile data.
> 
> Yes. I completely understand the motivation behind pledge, unveil and
> similar constructs. I also understand that it sort of runs counter to
> using one of the world's most secure-by-default operating systems if you
> then run an insecure monstrosity on top of it. I was just starting to
> like the OpenBSD experience as a user and sysadmin. :-)
> 
> But I also think that it is unrealistic to expect applications to be
> written to the same standard as OpenBSD, given the resources needed for
> that. Many startups would never get off the ground if that were the
> case.
> 
> > I can fully see why Ingo would say "I would not run things like that
> > exposed", partly because I figure he actually has a choice to not do
> > it, but regardless of what electric fences you like (Selinux,
> > capsicum, pledge/unveil, chroots) if you create a huge monolith
> > running in an environment which actively prevents you from activating
> > any kinds of protections, then I can see how you would see some
> > friction.
> 
> I would like to get more information about doing application programming
> for an OS like OpenBSD. I understand that if you program your
> applications in C, you have readily available pledge/unveil, etc. But
> many applications are written in higher-level languages, and in my case
> at least, it seems to be nearly impossible to write a secure application
> without changing to C or some other language that can easily use
> OpenBSD's system calls. And for a mediocre programmer, or just an
> inexperienced one, it exposes you to a whole host of other problems that
> can lead to worse security and quality.
> 
> The solution is probably just to be a good programmer. ;-)
> 

For the record, I am also interested in information on how pledge(2) and
unveil(2) would interact with a "higher level language". I would also 
be happy to learn more about how they interact with assembly. My
conceptual understanding can probably still be improved upon.
In the spirit of not demanding to much time from my contemporaries I
am especially greatful for pointers to conceptual documentation and to
implementation documentation. I have the impression that it seems
effective to get a conceptual overview first.

[[ I have the suspicion that being a good programmer crucially depends
on having conceptual understanding. Maybe it also depends on practice.]]

Concretely:
Just to start off easy, how can I find conceptual documentation on
what an operating system "process" is in OpenBSD and how deeply a libc
is tied into that by design? As far as I am aware a process has the
"current working directory" associated with it, in order to be able to
resolve relative paths and is also where "environment variables" are
stored.  These remind me of dynamic bindings, at least in spirit. I am
only aware of plain C having lexical bindings, in contrast to this.

(I am also still fuzzy on how intertwined an operating system and a CPU
are. From my superficial understanding, e.g.  the operating system has
to be aware of the MMU. I am concretely speaking of amd64 territory
here.)

https://man.openbsd.org/process :
did not turn up anything

https://man.openbsd.org/pledge  :
where is further information on what a process is?

https://man.openbsd.org/unveil :
where is further information on what a process is?




Best Regards,

Andrew

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote:
> Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen 
> :
> >  > Properly starting up a daemon process requires several steps,
> >  > often involving unveil(2), pledge(2), chroot(2), prviledge
> >  > dropping, sometimes fork+exec for privilege separation, and so on
> > 
> >  The process I need to run is written in Clojure and thus runs on the
> >  Java Virtual Machine. Do you have any suggestions on how to best go
> >  about making it "daemon-like"? I am not sure that I can call unveil(2),
> >  pledge(2) and chroot(2) from Clojure without some strange sorcery.
> 
> So not related to only Clojure but rather on runtimes that are large
> and unwieldy, this seems to be exactly why plegde() and unveil() came
> into being in the first place, after seeing things that needs to do
> certain privileged operations at some early point, but because of
> design/runtime/hard-to-pledge or whatever has to run with the sum of
> all privileges, all capabilities at all times and at the same time
> being exposed to potential hostile data.

Yes. I completely understand the motivation behind pledge, unveil and
similar constructs. I also understand that it sort of runs counter to
using one of the world's most secure-by-default operating systems if you
then run an insecure monstrosity on top of it. I was just starting to
like the OpenBSD experience as a user and sysadmin. :-)

But I also think that it is unrealistic to expect applications to be
written to the same standard as OpenBSD, given the resources needed for
that. Many startups would never get off the ground if that were the
case.

> I can fully see why Ingo would say "I would not run things like that
> exposed", partly because I figure he actually has a choice to not do
> it, but regardless of what electric fences you like (Selinux,
> capsicum, pledge/unveil, chroots) if you create a huge monolith
> running in an environment which actively prevents you from activating
> any kinds of protections, then I can see how you would see some
> friction.

I would like to get more information about doing application programming
for an OS like OpenBSD. I understand that if you program your
applications in C, you have readily available pledge/unveil, etc. But
many applications are written in higher-level languages, and in my case
at least, it seems to be nearly impossible to write a secure application
without changing to C or some other language that can easily use
OpenBSD's system calls. And for a mediocre programmer, or just an
inexperienced one, it exposes you to a whole host of other problems that
can lead to worse security and quality.

The solution is probably just to be a good programmer. ;-)

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

On Thu, Jan 30, 2020, at 23:32, Ingo Schwarze wrote:
> In general, size and complexity tend to hurt security, but i know
> too little about Java to say how relevant that general rule of thumb
> is to the question of running a daemon using a Java Virtual Machine.
> For example, Perl 5 is also a fairly large and complex system, but
> it still supports writing daemons that are secure enough for many
> purposes, when used properly - even though i'd probably prefer a
> simpler approach when i have a choice.

Trying to learn some valuable lessons from our interaction, could you
give some examples of what you mean by 'simpler approach' in this
context?

Do you mostly do systems programming?

Best regards,
Patrick

Re: FreeBSD daemon(8)-like command for OpenBSD

[Janne Johansson]

Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen <
patr...@tamstrup.dk>:

> > Properly starting up a daemon process requires several steps, often
> > involving unveil(2), pledge(2), chroot(2), prviledge dropping,
> > sometimes fork+exec for privilege separation, and so on
>
> The process I need to run is written in Clojure and thus runs on the
> Java Virtual Machine. Do you have any suggestions on how to best go
> about making it "daemon-like"? I am not sure that I can call unveil(2),
> pledge(2) and chroot(2) from Clojure without some strange sorcery.


So not related to only Clojure but rather on runtimes that are large and
unwieldy,
this seems to be exactly why plegde() and unveil() came into being in
the first place, after seeing things that needs to do certain privileged
operations
at some early point, but because of design/runtime/hard-to-pledge or
whatever has
to run with the sum of all privileges, all capabilities at all times and at
the same time being exposed to potential hostile data.

I can fully see why Ingo would say "I would not run things like that
exposed",
partly because I figure he actually has a choice to not do it, but
regardless
of what electric fences you like (Selinux, capsicum, pledge/unveil, chroots)
if you create a huge monolith running in an environment which actively
prevents you from activating any kinds of protections, then I can see how
you would see some friction.

-- 
May the most significant bit of your life be positive.

Re: FreeBSD daemon(8)-like command for OpenBSD

[Martin Schröder]

Am Do., 30. Jan. 2020 um 21:06 Uhr schrieb Patrick Kristiansen
:
> The process I need to run is written in Clojure and thus runs on the
> Java Virtual Machine. Do you have any suggestions on how to best go
> about making it "daemon-like"? I am not sure that I can call unveil(2),

There is jsvc/apache commons daemon.
Don't know how good that works on OpenBSD, though.

Best
Martin

Re: FreeBSD daemon(8)-like command for OpenBSD

[Daniel Dickman]




>> On Jan 30, 2020, at 4:34 PM, Patrick Kristiansen  wrote:
> On Thu, Jan 30, 2020, at 21:10, Ingo Schwarze wrote:
>> Hi Patrick,
>> 
>> Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 09:05:11PM +0100:
>> 
>>> The process I need to run is written in Clojure and thus runs on the
>>> Java Virtual Machine.  Do you have any suggestions on how to best go
>>> about making it "daemon-like"?
>> 
>> No, i'm sorry i have no advice on that.  I would certainly not run
>> soemthing like that under any circumstances, on any machine, and even
>> less so on any machine connected to the Internet.
> 
> Out of genuine curiosity, and not to be inflammatory, are you saying
> that running any internet-facing service/process/program is inadvisible

Hi Patrick, one of the risks is something like blind ROP. To quote from the 
website (emphasis mine):

“requires a stack overflow and a *service that restarts after a crash*”

https://www.scs.stanford.edu/brop/


> under all circumstances if not written to the standards of a daemon
> shipping with OpenBSD and with the facilities (pledge, unveil, etc.)
> available in OpenBSD?
> 
> Best regards,
> Patrick

Re: FreeBSD daemon(8)-like command for OpenBSD

[Ingo Schwarze]

Hi Patrick,

Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 10:23:52PM +0100:
> On Thu, Jan 30, 2020, at 21:10, Ingo Schwarze wrote:
>> Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 09:05:11PM +0100:

>>> The process I need to run is written in Clojure and thus runs on the
>>> Java Virtual Machine.  Do you have any suggestions on how to best go
>>> about making it "daemon-like"?

>> No, i'm sorry i have no advice on that.  I would certainly not run
>> soemthing like that under any circumstances, on any machine, and even
>> less so on any machine connected to the Internet.

> Out of genuine curiosity, and not to be inflammatory, are you saying
> that running any internet-facing service/process/program is inadvisible
> under all circumstances if not written to the standards of a daemon
> shipping with OpenBSD and with the facilities (pledge, unveil, etc.)
> available in OpenBSD?

No, i didn't intend to say that.

I do think that automatically restarting crashy daemons is a terrible
idea and hence the OpenBSD base system intentionally provides no
support for that.  I also said that i personally doubt the wisdom
of constructing a wrapper to run a program as a daemon that is not
designed as a daemon but simply using stdout and stderr and so on.

But in what you quote above, i tried to be careful to only say
that *I*, personally, would not run a Java Virtual Machine and
cannot provide advice on that.

In general, size and complexity tend to hurt security, but i know
too little about Java to say how relevant that general rule of thumb
is to the question of running a daemon using a Java Virtual Machine.
For example, Perl 5 is also a fairly large and complex system, but
it still supports writing daemons that are secure enough for many
purposes, when used properly - even though i'd probably prefer a
simpler approach when i have a choice.

I believe some Java infrastructure and programs exist in the ports
tree, but i can't help you with that.

Yours,
  Ingo

Re: FreeBSD daemon(8)-like command for OpenBSD

[KatolaZ]

On Thu, Jan 30, 2020 at 09:05:11PM +0100, Patrick Kristiansen wrote:

[cut]

> 
> The process I need to run is written in Clojure and thus runs on the
> Java Virtual Machine. Do you have any suggestions on how to best go
> about making it "daemon-like"? I am not sure that I can call unveil(2),
> pledge(2) and chroot(2) from Clojure without some strange sorcery. I
> read in some blog post, that the way to detach from the controlling
> terminal is by closing stdin, stdout and stderr, which I admittedly
> haven't tried.
>

Closing stdin/stdout/stderr is not enough. You also need to detach the
process from the controlling terminal (which is done by calling
setsid(2) after the first fork), re-fork so that the process is not a
session leader and does not acquire a new controlling terminal (and is
re-parented to init), set an appropriate umask, move to an appropriate
dir, drop privileges, and so on...

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

On Thu, Jan 30, 2020, at 21:10, Ingo Schwarze wrote:
> Hi Patrick,
> 
> Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 09:05:11PM +0100:
> 
> > The process I need to run is written in Clojure and thus runs on the
> > Java Virtual Machine.  Do you have any suggestions on how to best go
> > about making it "daemon-like"?
> 
> No, i'm sorry i have no advice on that.  I would certainly not run
> soemthing like that under any circumstances, on any machine, and even
> less so on any machine connected to the Internet.

Out of genuine curiosity, and not to be inflammatory, are you saying
that running any internet-facing service/process/program is inadvisible
under all circumstances if not written to the standards of a daemon
shipping with OpenBSD and with the facilities (pledge, unveil, etc.)
available in OpenBSD?

Best regards,
Patrick

Re: FreeBSD daemon(8)-like command for OpenBSD

[Ingo Schwarze]

Hi Patrick,

Patrick Kristiansen wrote on Thu, Jan 30, 2020 at 09:05:11PM +0100:

> The process I need to run is written in Clojure and thus runs on the
> Java Virtual Machine.  Do you have any suggestions on how to best go
> about making it "daemon-like"?

No, i'm sorry i have no advice on that.  I would certainly not run
soemthing like that under any circumstances, on any machine, and even
less so on any machine connected to the Internet.

Yours,
  Ingo

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

Hi Ingo,

On Thu, Jan 30, 2020, at 18:35, Ingo Schwarze wrote:
> Hi Patrick,
> 
> Patrick Kristiansen wrote on Tue, Jan 28, 2020 at 09:29:20AM +0100:
> 
> > But another use for daemon(8) is for its ability to detach the child
> > process from the controlling terminal and furthermore redirect its
> > stdout/stderr to syslog. Is there some mechanism to do that from the
> > shell? Perhaps a combination of nohup and starting a background job?
> 
> That doesn't strike me as a particularly bright idea either.
>
> Properly starting up a daemon process requires several steps, often
> involving unveil(2), pledge(2), chroot(2), prviledge dropping,
> sometimes fork+exec for privilege separation, and so on. Typically,
> these steps need to be intermixed in exactly the right order with
> option parsing, environment parsing, parsing of configuration files
> and various kinds of initialization.

The process I need to run is written in Clojure and thus runs on the
Java Virtual Machine. Do you have any suggestions on how to best go
about making it "daemon-like"? I am not sure that I can call unveil(2),
pledge(2) and chroot(2) from Clojure without some strange sorcery. I
read in some blog post, that the way to detach from the controlling
terminal is by closing stdin, stdout and stderr, which I admittedly
haven't tried.

> Writing wrappers usually just doesn't work, and it seems doubtful to
> me whether daemon(8) is up to what is usually needed.

If I were writing my program in C, I could fairly easily call daemon(3),
I guess, but I am not. I am starting to think that tmux(1) would be the
easiest way to go about it on OpenBSD... but it feels wrong.

Best regards,
Patrick

Re: FreeBSD daemon(8)-like command for OpenBSD

[Ingo Schwarze]

Hi Patrick,

Patrick Kristiansen wrote on Tue, Jan 28, 2020 at 09:29:20AM +0100:

> But another use for daemon(8) is for its ability to detach the child
> process from the controlling terminal and furthermore redirect its
> stdout/stderr to syslog. Is there some mechanism to do that from the
> shell? Perhaps a combination of nohup and starting a background job?

That doesn't strike me as a particularly bright idea either.

Properly starting up a daemon process requires several steps,
often involving unveil(2), pledge(2), chroot(2), prviledge
dropping, sometimes fork+exec for privilege separation,
and so on.  Typically, these steps need to be intermixed in
exactly the right order with option parsing, environment
parsing, parsing of configuration files and various kinds
of initialization.

Writing wrappers usually just doesn't work, and it seems doubtful
to me whether daemon(8) is up to what is usually needed.

Some sh(1) code quickly hacked together may be good enough for
testing purposes, but i doubt that you want to use such a hack
for a real daemon that you are planning to run in production on 
the Internet.

Yours,
  Ingo

Re: FreeBSD daemon(8)-like command for OpenBSD

[Christopher Sean Hilton]

On Wed, Jan 29, 2020 at 09:46:10AM +, Kevin Chadwick wrote:
> On 2020-01-27 19:13, Patrick Kristiansen wrote:
> > Is there something like the FreeBSD daemon(8) command for OpenBSD, which
> > can run a process in the background and restart it if it crashes?
> 
> Of course init does this for getty but as others have pointed out, restarting
> daemons listening to the network during unexpected occurrences, like the 
> kernel
> killing it during exploitation is a terrible default. I hear it in GoLang all
> the time and it irks me. I am against panic handling in Go generally but 
> perhaps
> there will be some occasion where it may be of some use for semi-unexpected
> issues (perhaps hw redundancy, though generally that is better handled by 
> having
> redundant complete systems).
> 
> You can always use monit from pkg/ports for anything you have decided is an
> exception but it is good that OpenBSD makes people stop and think and maybe 
> fix
> first.
> 

I understand the security issues involved and I *completely* agree
with all who posted on them above.

Having said that, I'll add that the complete source code from the
FreeBSD daemon(8) program is on any FreeBSD system that has source
code package installed at:

  your-freebsd-system.your-domain.your-tld:/usr/src/usr.sbin/daemon

free for you to grab. It should therefore be trivial to get FreeBSD's
daemon(8) onto your OpenBSD box by grabbing the source from a FreeBSD
box and building it on your OpenBSD system.

I would emphasize that this is only the best option if, you're most
comfortable with daemon(8) as opposed to something from OpenBSD's
pkg/ports tree, and you can build it from source. Otherwise you'd be
better off installing one of the many ports/packages designed to
manage and restart daemons mentioned above.


-- 
Chris

 __o  "All I was trying to do was get home from work."
   _`\<,_   -Rosa Parks
___(*)/_(*)_
Christopher Sean Hilton[chris/at/vindaloo/dot/com]

Re: FreeBSD daemon(8)-like command for OpenBSD

[Kevin Chadwick]

On 2020-01-27 19:13, Patrick Kristiansen wrote:
> Is there something like the FreeBSD daemon(8) command for OpenBSD, which
> can run a process in the background and restart it if it crashes?

Of course init does this for getty but as others have pointed out, restarting
daemons listening to the network during unexpected occurrences, like the kernel
killing it during exploitation is a terrible default. I hear it in GoLang all
the time and it irks me. I am against panic handling in Go generally but perhaps
there will be some occasion where it may be of some use for semi-unexpected
issues (perhaps hw redundancy, though generally that is better handled by having
redundant complete systems).

You can always use monit from pkg/ports for anything you have decided is an
exception but it is good that OpenBSD makes people stop and think and maybe fix
first.

Re: FreeBSD daemon(8)-like command for OpenBSD

[Thomas Bohl]

But another use for daemon(8) is for its ability to detach the child
process from the controlling terminal 


If it is about a rc.d script, you can add

rc_bg=YES

to it.

Re: FreeBSD daemon(8)-like command for OpenBSD

[Marc Chantreux]

hello,

> PID=`pgrep gloob`  
> if [ -z "$PID" ]  
>      then
>     /usr/local/bin/gloob -f poor_security_a_bad_idea_to_run.conf
>      fi

is there a reason to not use the pgrep status ?

pgrep -q gloob  || /usr/local/bin/gloob

regards,

marc

Re: FreeBSD daemon(8)-like command for OpenBSD

[Allan Streib]

You asked about the base image, so maybe there is some reason you can't
use it, but Supervisor is in ports/packages.

Allan

Patrick Kristiansen  writes:

> Hi everyone,
>
> Is there something like the FreeBSD daemon(8) command for OpenBSD, which
> can run a process in the background and restart it if it crashes? That
> is, is there a command that comes with OpenBSD's base image with these
> capabilities? Surprisingly, Google hasn't revealed anything useful to
> me.
>
> Thanks,
> Patrick Kristiansen
>

Re: FreeBSD daemon(8)-like command for OpenBSD

[Martijn van Duren]

On 1/28/20 9:29 AM, Patrick Kristiansen wrote:
> Hi Ingo
> 
> Thank you for your reply.
> 
> I can't say I disagree with your and the OpenBSD team's attitude about
> bug-free daemons. But I am just a lowly application programmer, and
> sometimes I introduce horrible bugs that make our systems crash. In many
> cases it will be preferable to just start the process again (and, of
> course, fix the bug) for the purposes of keeping our business running.

Everyone has a testing environment, not everyone has a production
environment...
> 
> But another use for daemon(8) is for its ability to detach the child
> process from the controlling terminal and furthermore redirect its
> stdout/stderr to syslog. Is there some mechanism to do that from the
> shell? Perhaps a combination of nohup and starting a background job?

I once had to write a support script in shell that needed to run as
daemon, basically some action needed to be taken if something was found
in a log-file. To do this I did exactly what you said:
nohup  2>&1 | logger  &
and put this inside an rc.d file or equivalent format of your OS of
choice.

now I'm not promoting this kind of hackery, but this worked for me
quite reliably at the time.

martijn@
> 
> Best regards,
> Patrick
> 
>> Hi Patrick,
>>
>> Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:
>>
>>> Is there something like the FreeBSD daemon(8) command for OpenBSD,
>>> which can run a process in the background and restart it if it
>>> crashes?
>>
>> Absolutely not, we are strongly convinced this is an utterly stupid
>> idea and a serious security risk.
>>
>> If a daemon crashes, it has a bug.  Many bugs that cause crashes
>> are also exploitable.  So if a daemon crashes, you first have to
>> understand why it crashed, fix or at least mitigate the bug, and
>> can only restart it afterwards.
>>
>> Restarting it automatically is an irresponsible thing to do.
>>
>> If a daemon keeps crashing so frequently that you can only run it
>> in production with automatic restarts, then running it at all is
>> irresponsible in the first place.
>>
>> Yours,
>>  Ingo
> 

Re: FreeBSD daemon(8)-like command for OpenBSD

[Paul de Weerd]

Hi Patrick,

On Tue, Jan 28, 2020 at 09:29:20AM +0100, Patrick Kristiansen wrote:
| Hi Ingo
| 
| Thank you for your reply.
| 
| I can't say I disagree with your and the OpenBSD team's attitude about
| bug-free daemons. But I am just a lowly application programmer, and
| sometimes I introduce horrible bugs that make our systems crash. In many
| cases it will be preferable to just start the process again (and, of
| course, fix the bug) for the purposes of keeping our business running.
| 
| But another use for daemon(8) is for its ability to detach the child
| process from the controlling terminal and furthermore redirect its
| stdout/stderr to syslog. Is there some mechanism to do that from the
| shell? Perhaps a combination of nohup and starting a background job?

What I do to run a "normal" (non-daemon) program like a daemon, is to
start it in tmux.  To have this start during system startup, I have an
@reboot cronjob:

--
[weerd@cube] $ cat ~/bin/conlog
#!/bin/sh
# conlog: start a tmux session with cu logging to a file
##

# Can be used with the following @reboot cron line to start at boot:
#
# @reboot   /home/weerd/bin/conlog

PATH=/bin:/usr/bin

LOG="/home/weerd/data/conlog/log.`date +%s`"

mkdir -p `dirname ${LOG}`
tmux new -d "script -c 'cu -l cuaU0 -s 115200' ${LOG}"
--

At reboot, this will start a new (detached) tmux session that launches
cu (under script) to log the serial console output from another
OpenBSD machine.  I can attach the tmux session and interact with the
console of that machine if necessary.

For the purpose of restarting crashing programs, you could do
something similar: run your program in a tmux session (convenient to
attach to when you want to look at its stdout/stderr output) and
script something to restart when it errors out.  You could then also
send yourself e-mail to alert you to the restart.

Cheers,

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

Hi Ingo

Thank you for your reply.

I can't say I disagree with your and the OpenBSD team's attitude about
bug-free daemons. But I am just a lowly application programmer, and
sometimes I introduce horrible bugs that make our systems crash. In many
cases it will be preferable to just start the process again (and, of
course, fix the bug) for the purposes of keeping our business running.

But another use for daemon(8) is for its ability to detach the child
process from the controlling terminal and furthermore redirect its
stdout/stderr to syslog. Is there some mechanism to do that from the
shell? Perhaps a combination of nohup and starting a background job?

Best regards,
Patrick

> Hi Patrick,
> 
> Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:
> 
>> Is there something like the FreeBSD daemon(8) command for OpenBSD,
>> which can run a process in the background and restart it if it
>> crashes?
> 
> Absolutely not, we are strongly convinced this is an utterly stupid
> idea and a serious security risk.
> 
> If a daemon crashes, it has a bug.  Many bugs that cause crashes
> are also exploitable.  So if a daemon crashes, you first have to
> understand why it crashed, fix or at least mitigate the bug, and
> can only restart it afterwards.
> 
> Restarting it automatically is an irresponsible thing to do.
> 
> If a daemon keeps crashing so frequently that you can only run it
> in production with automatic restarts, then running it at all is
> irresponsible in the first place.
> 
> Yours,
>  Ingo

Re: FreeBSD daemon(8)-like command for OpenBSD

[aisha]

I generally do this on a user level with some editors like emacs,
cuz I run spacemacs which is prone to crashes, cuz of over 9000 plugins

Small improvement: Keep a PID file, along with pgrep, because of 
multiple emacs-server instances


It has worked a bit better than simple pgrep

If anyone has any improvements, would love to know.

---
Aisha
blog.aisha.cc

On 2020-01-27 18:21, dagricha...@speakeasy.net wrote:

Irresponsible people like myself have been known to put cron jobs in
place to look for, and if necessary restart crashy daemons.

This could referred to as a kludge, though many would argue that is to
mild an aspersion to cast upon it.


PID=`pgrep gloob`
if [ -z "$PID" ]  
     then
     
    /usr/local/bin/gloob -f poor_security_a_bad_idea_to_run.conf

     fi


Dag H. Richards - Distinguished Dunning-Kruger Fellow 2020 

as seen on unixadminsgonewild.com
 



On Mon, 27 Jan 2020 22:41:00 +0100, Ingo Schwarze  
wrote:


Hi Patrick,

Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:


Is there something like the FreeBSD daemon(8) command for OpenBSD,
which can run a process in the background and restart it if it
crashes?


Absolutely not, we are strongly convinced this is an utterly stupid
idea and a serious security risk.

If a daemon crashes, it has a bug. Many bugs that cause crashes
are also exploitable. So if a daemon crashes, you first have to
understand why it crashed, fix or at least mitigate the bug, and
can only restart it afterwards.

Restarting it automatically is an irresponsible thing to do.

If a daemon keeps crashing so frequently that you can only run it
in production with automatic restarts, then running it at all is
irresponsible in the first place.

Yours,
Ingo

Hi Patrick,

Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:


Is there something like the FreeBSD daemon(8) command for OpenBSD,
which can run a process in the background and restart it if it
crashes?


Absolutely not, we are strongly convinced this is an utterly stupid
idea and a serious security risk.

If a daemon crashes, it has a bug. Many bugs that cause crashes
are also exploitable. So if a daemon crashes, you first have to
understand why it crashed, fix or at least mitigate the bug, and
can only restart it afterwards.

Restarting it automatically is an irresponsible thing to do.

If a daemon keeps crashing so frequently that you can only run it
in production with automatic restarts, then running it at all is
irresponsible in the first place.

Yours,
Ingo
 

Re: FreeBSD daemon(8)-like command for OpenBSD

[dagrichards]

Irresponsible people like myself have been known to put cron jobs in place to 
look for, and if necessary restart crashy daemons.

This could referred to as a kludge, though many would argue that is to mild an 
aspersion to cast upon it.


PID=`pgrep gloob`  
if [ -z "$PID" ]  
     then
     
    /usr/local/bin/gloob -f poor_security_a_bad_idea_to_run.conf

     fi


Dag H. Richards - Distinguished Dunning-Kruger Fellow 2020 

as seen on unixadminsgonewild.com
 



On Mon, 27 Jan 2020 22:41:00 +0100, Ingo Schwarze  wrote:

Hi Patrick,

Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:

> Is there something like the FreeBSD daemon(8) command for OpenBSD,
> which can run a process in the background and restart it if it
> crashes?

Absolutely not, we are strongly convinced this is an utterly stupid
idea and a serious security risk.

If a daemon crashes, it has a bug. Many bugs that cause crashes
are also exploitable. So if a daemon crashes, you first have to
understand why it crashed, fix or at least mitigate the bug, and
can only restart it afterwards.

Restarting it automatically is an irresponsible thing to do.

If a daemon keeps crashing so frequently that you can only run it
in production with automatic restarts, then running it at all is
irresponsible in the first place.

Yours,
Ingo

Hi Patrick,

Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:

> Is there something like the FreeBSD daemon(8) command for OpenBSD,
> which can run a process in the background and restart it if it
> crashes?

Absolutely not, we are strongly convinced this is an utterly stupid
idea and a serious security risk.

If a daemon crashes, it has a bug. Many bugs that cause crashes
are also exploitable. So if a daemon crashes, you first have to
understand why it crashed, fix or at least mitigate the bug, and
can only restart it afterwards.

Restarting it automatically is an irresponsible thing to do.

If a daemon keeps crashing so frequently that you can only run it
in production with automatic restarts, then running it at all is
irresponsible in the first place.

Yours,
Ingo
 

Re: FreeBSD daemon(8)-like command for OpenBSD

[Ingo Schwarze]

Hi Patrick,

Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100:

> Is there something like the FreeBSD daemon(8) command for OpenBSD,
> which can run a process in the background and restart it if it
> crashes?

Absolutely not, we are strongly convinced this is an utterly stupid
idea and a serious security risk.

If a daemon crashes, it has a bug.  Many bugs that cause crashes
are also exploitable.  So if a daemon crashes, you first have to
understand why it crashed, fix or at least mitigate the bug, and
can only restart it afterwards.

Restarting it automatically is an irresponsible thing to do.

If a daemon keeps crashing so frequently that you can only run it
in production with automatic restarts, then running it at all is
irresponsible in the first place.

Yours,
  Ingo

FreeBSD daemon(8)-like command for OpenBSD

[Patrick Kristiansen]

Hi everyone,

Is there something like the FreeBSD daemon(8) command for OpenBSD, which
can run a process in the background and restart it if it crashes? That
is, is there a command that comes with OpenBSD's base image with these
capabilities? Surprisingly, Google hasn't revealed anything useful to
me.

Thanks,
Patrick Kristiansen