On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST)
karl@??? wrote:

> Enrico Weigelt:
> ...
> > Let's just take some example: libsrvmgt with funcs like that:
> >
> > * srvmgt_daemonize()
> > --> detach from controlling terminal, etc
>
> Why do any monitor program need to know if the program has detached
> or not, the only thing it needs to know is the pid and the state,
> which would/could be provided by the *_state() functions,
> or am I wrong ?

All daemons detach from the control terminal. The monitor and the
daemon must coordinate each other about who's doing the detach to avoid
launch time failures.

> > * srvmgt_droppriv(...)
> > --> drop root privileges (if we are still root)
> > --> several versions, eg. with fetching the target uid/gid from env
>
> Given the pid, it isn't that hard for a monitor to find the uid/gid of
> the process, why has this have to go through the monitor ?

I don't think here the monitor is used to extract process info (such
as user/group it's running under), rather the environment is used to
determine what user:group the daemon must be set to by the monitor.

> Also, given that you can do the above without this lib opens gives the
> program the option too cheat, say, if the monitor wishes to have a
> tight control of the process.

It depends by where is that environment set. It might be a config
file. You're supposed to trust your config files.

[...]

> > * srvmgt_report_state(...)
> --> report the service state to the supervisor
> ...
>
> There could be something like *_a_would_like_to_be_monitored() and
> *_I_wish_to_regain_my_free_will().

The monitor is supposed to implement local security/service
continuity/resource allocation policies the daemon must not be able to
bail itself out of.

> >  --> states could be eg.  
> >    * SRVMGT_STATE_STARTUP     -- still within the startup phase
> >    * SRVMGT_STATE_READY_LOCAL -- ready for local clients only
> >    * SRVMGT_STATE_READY_ALL   -- ready for all clients
> >    * SRVMGT_STATE_BUSY        -- too busy to process new requests
> >    * SRVMGT_STATE_SHUTDOWN    -- shutting down, still finishing
> >                                      queued requests
> >    * SRVMGT_STATE_DEFERRED    -- temporarily can't accept new
> >                                      requests (eg. overload)
> >    * SRVMGT_STATE_WAITING     -- wait for resource (eg. printer
> >                                      needs paper or ink)
> >    * SRVMGT_STATE_OFFLINE     -- completely offline (eg. due some
> >                                      fatal error)  

>
> Given the choises given, it seems that the target of the monitor is
> network servers. Couldn't the monitor find out the ready_local,
> ready_all and shutdown by itself by monitoring which ports are open ?

The monitor is not supposed to always grant any daemon any port it
wishes. Monitors are there also to prevent daemons to do just as they
will. One thing is to trust the monitor, another thing is to trust the
whole collection of deamons it manages.

[...]

> ///
>
> And, what if the monitor cannot trust the program it monitors ?
> Given the lib suggestion, it seems that we are trusting the program.

Well... what if you do not trust the monitor?
What do you mean by what you wrote? How do you think you can teach a
monitor if some program can be trusted? I don't think I will love a
monitor that is not going to start, say, the sshd daemon because it
thinks it cannot be trusted. I must know what it means by this (bad to
system security? to the available resourses?), I want to know the
specific reason it believes sshd is bad and I want this behaviour to be
configurable.

> But what if if we don't know if we can trust the walues provided by
> the program, the we have to check what the program is really doing,
> and then the lib have no value, isn't that so ?

Could you please provide us with an example of untrusted
behaviour/program provided data that the monitor is supposed to detect
and handle accordingly?


Alessandro