On Fri, Oct 02, 2020 at 02:46:45PM +0300, Arseny Maslennikov wrote:
> > > There's a misunderstanding here. I'm not asking to explain the
> > > semantics (what this patch does) — I repeat, it's rather obvious from
> > > the source itself, the patch is indeed simple. I'm trying to get how the
> > > patch's author would describe the pragmatic value of this patch. IOW:
> > > we see this patch does XXX. What, in Alexey's view, are we trying to
> > > achieve by implementing XXX?
> > 
> > I remember that this patch was the result of a discussion with ldv.
> 
> That discussion then likely was not public; in part, that's why I'm asking.

Yeah. Sometimes it happens.

> > The
> > idea was that the admin would prepare the system for use of cgroups by the
> > hasher-privd daemon.
> 
> If I understood correctly ^U
> To put it another way, we're doing this because the machine admin might
> want hasher-privd to put the processes it spawns in cgroups
> _at_an_arbitrary_path_, at the administrator's discretion.
> 
> Ok, this is a valid explanation and a valid feature. Thank you.

Yes. This is an optional feature for the administrator.

> > I'm not considering the hasher-privd as an end user server. This is a
> > low-level server on which you can build different solutions. I don't mean
> > just hasher.
> 
> Subject: the future of hasher-privd
> 
> I'm not particularly opposed to the expansion of hasher-privd's utility
> scope; there are quite a lot of potential use cases: hasher-privd as a
> general-purpose cgroup manager, hasher-privd as a daemon-based
> NO_NEW_PRIVS-ready policy-enforcing "su -", ...

At the time when I made this patch and thought in the future to try to
make the hasher-privd more general-purpose.

I had thoughts to add support for seccomp via the libkafel library, extend
the use of namespaces (user, pid, time, etc).

Another thought was not directly related to hasher-privd. I was thinking
about trying to implement the creation of a chroot from docker images.

> While this sounds interesting, I believe there are currently some
> obstacles. Would those solutions on top of hasher-privd be
> co-installable and co-existing on a single machine? E.g. two hasher-privd
> init scripts with different configuration files for different things,
> spawning different processes.

The hasher-priv/hasher-privd has a global configuration. As long as
different solutions are able to use it together, they can coexist. But
this reuse of the server seems a little strange to me.

> Or they wouldn't? Or a single hasher-privd instance — aka node, aka main
> process if you will — would do both services? I don't yet have a picture
> of this in my head; this will have to be thought out.
> 
> Will the decoupled, generic hasher-privd have to expand its IPC API?

I didn't expect the API to be public. I mean it will be used by someone
other than the hasher-priv. I didn't think that far.

I propose to postpone this question. We don't even have a server yet.

> If we decouple hasher-privd from hasher, this would also mean we support
> arbitrary clients, so we'll have to formally define the IPC interface,
> see my concerns on it in a previous mail.

Yep. When this happens, we will need to make a thoughtful public API.

> As it stands now, the hasher project currently sees hasher-privd as its
> vital component, a specialized tool for a special purpose, configured at
> /etc/hasher-priv/. You're proposing something different.
> 
> In short, it's gonna be a long road.

True.
 
> > With this in mind, I don't think that this server should do
> > everything out of the box without configuration.
> 
> I believe the hasher project _would_ want some sane out-of-the-box
> configuration. The generic privd you describe above might not, much like
> runc/crun do not, but the hasher project definitely would. Furthermore, in
> my personal (but shared by many) opinion, this hasher OOTB experience
> would have to be catered to the common case of an ALT Team developer,
> not to public builder services (which are already expected to take care
> to tune and harden their non-trivial configuration, and we can even ship
> recommendations for their use case in /usr/share/doc).

I agree with you but let's not do it all at once. I have not been able to
upstream the basic server implementation. I'm afraid more global changes
will be accepted even slower.

> The approach you suggest here could work, if e. g. the decoupled privd
> is shipped with no defaults, and the hasher project ships its own
> defaults for the desired operation of privd.

-- 
Rgrds, legion