On 18/04/2017 at 10:35, karl@??? wrote:
> 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 ?

Isn't init a daemon? Isn't inetd/xinetd 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 ?

In the case of init being the monitor, it can check if it's parent has
PID 1. The classical approach is to configure the daemon to do the
right thing, i.e. to do the detach himself when run with the --daemon
switch or when the config file has a similar item configured, to let the
monitor do it otherwise or if explicitly told not to daemonize (some
programs have a --no-daemon or --foreground or --debug switch to
override the config file settings). This is old-school Unix, classical
Unix daemon have had these items (switches and config files) for many
ten years... the modern approach in Linux entails IPC, dbus, sockets to
have messages passed from the monitor to daemons and back.

> And if it doesn't know, how can one demand that it should
> coordinate with something unknown ?

Config files, command line switches.

> And why should a program/daemon care if
> it has a monitor or not ?

Why should a car driver care if the traffic light has the red or the
green light turned on?
Why should a sysadmin care if the OS he uses runs systemd 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 ?

Again, as far as I understood what Enrico Weigelt wrote, the monitor
does not want to know the user:group the daemons runs under, it needs to
*set* them to the appropriate values when it launches the daemon to have
them reflect config file settings or local policies.

> And if it should know it, why trust
> the monitored program when the kernel can give you the info ?

Again, the relevant info is supposed to be set in config files. The
user:group the daemon must run under is not up to the daemon itself,
they are set in config files, either the deamon's or the monitor's.

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

That the relevant info is set in the config files, they are not made
up by the program itself and trusted by the monitor. The trust is
placed into the 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.
> It seems you have the view that a monitor has to police a program.

Many monitor also do this, some are setup mainly for this reason.
Xinetd has several config items related to security or resource
policing: some "flags" (like IDONLY and INTERCEPT), the "user" and
"group" settings, "libwrap", "only_from", "no_access", "access_times",
"redirect", "bind", "per_source", "cps" (connections per second),
"max_load", "umask", "rlimit_(as|cpu|data|rss|stack)", "passenv",
"deny_time". It's good they are available, that you use them or don't.

> I don't think one should have such a strict view.

If you don't want them, don't use them. Let other people decide
otherwise, though. There is not a single use case that fits well
everyone's needs.

>>>>  --> 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 launches daemons. It's their parent. Being a parent bestows some
responsibilities.
Again: if you do not want to take advantage of the monitor's policing
capabilities, don't use them. But it's good that the monitor is capable
of implementing at least the very basic Unix security policy: run the
daemon under a non-privileged user:group.

> It seems you and I have different
> views about what a monitor is and should/shouldn't do.

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

But you need to, otherwise your employer is going to fire you. He did
not buy the server to use it as a door-stop and did not hire you to
contemplate empty racks.

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

What if you don't trust the kernel?

> If I can get the info I want from the
> kernel, why should I ask the program ?

Why is the kernel supposed to know what every possible daemon is
supposed to do and not to do? The kernel must do what the kernel is
for, that is provide the fundamental hardware and low level protocol
API. It must not be also a monitor/system policy enforcer/intrusion
detection system/... it must not be used as a repository of config file
settings for the generic daemon.

> If the kernel say something
> and the program something else, which one do you trust more ?

In my mind, should the kernel tell me a daemon is running as user1 and
should the daemon require to run as root, than the monitor should deny
the daemon's request unless explicitly configured to do so. This is the
monitor's job, because the monitor is the daemon process' parent.

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

Yes, we do.

> Second, you don't have to have any monitor except yourself, but as
> usual, you can automate part of it.

I do not, and cannot monitor myself all the daemons of all my firm's
datacenter computers. Monitors are good because they automate a lot of
the menial sysadmin chores. A "monitor" that only launches processes
leaves a lot to be desired. I get the feeling you consider all
computers to be like a personal workstation, where someone is always
sitting in front of them taking all the decisions about whatever is
running. Datacenters are not operated like this, they are to be fully
automated and placed in rooms the sysadmin only enters to perform
critical upgrades and maintenance tasks. A monitor that can only launch
processes and does not monitor them is, well, not a monitor.

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

This is yet another good reason a *monitor* is needed: it's the piece
of software that _monitors_ what it's children do and, when it detects
erroneous behavior, it take the appropriate action.

> Regards,
> /Karl Hammar

Alessandro