Alessandro Selli:
> 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.

A daemon from a daemon ?

> The monitor and the
> daemon must coordinate each other about who's doing the detach to avoid
> launch time failures.

The program to become the daemon, how does it knows if it has a monitor
or not ? And if it doesn't know, how can one demand that it should
coordinate with something unknown ? And why should a program/daemon care if
it has a monitor or not ?

> > > * 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.

I don't follow you. If the monitor shouldn't know much about the child
as stated by someone somewhere else in this thread, why should the
monitor need to know user:group ? And if it should know it, why trust
the monitored program when the kernel can give you the info ?

> > 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.

Or, rather, the user is responsible for the config file, not the program
reading it, so yes the program generally trusts the config file "since I
demand it". And what is your point ?

> > > * 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.

It seems you have the view that a monitor has to police a program.
I don't think one should have such a strict view.

> > >  --> 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.
...

Why, the monitor is not a firewall. It seems you and I have different
views about what a monitor is and should/shouldn't do.

> > 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?

Then I wouldn't run it, would you ?

> What do you mean by what you wrote? How do you think you can teach a
> monitor if some program can be trusted?
...

The monitor doesn't have to trust a specific program if it can get the
the wanted info from the kernel. If I can get the info I want from the
kernel, why should I ask the program ? If the kernel say something
and the program something else, which one do you trust more ?

> > 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?

First off, we seems to have different notions about what is a monitor.
Second, you don't have to have any monitor except yourself, but as
usual, you can automate part of it.
Third, not every program is bug free (it can give false values) nor
benign, there might be something on your system that someone else
implanted without you knowing.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57