Re: [systemd-devel] SystemCallFilter
On Di, 28.05.19 17:16, Josef Moellers (jmoell...@suse.de) wrote: > On 28.05.19 16:59, Lennart Poettering wrote: > > On Di, 28.05.19 14:04, Josef Moellers (jmoell...@suse.de) wrote: > > > >>> Regarding the syscall groupings: yes, the groups exist precisely to > >>> improve cases like this. That said, I think we should be careful not > >>> have an inflation of groups, and we should ask twice whether a group > >>> is really desirable before adding it. I'd argue in the open/openat > >>> case the case is not strong enough though: writing a filter > >>> blacklisting those is very difficult, as it means you cannot run > >>> programs with dynamic libraries (as loading those requires > >>> open/openat), which hence limits the applications very much and > >>> restricts its use to very few, very technical cases. In those case I > >>> have the suspicion the writer of the filters needs to know in very > >>> much detail what the semantics are anyway, and he hence isn't helped > >>> too much by this group. > >>> > >>> Note that the @file-system group already includes both, so maybe > >>> that's a more adequate solution? (not usable for blacklisting though, > >>> only for whirelisting, realistically). > >>> > >>> Hence, I would argue this is a documentation issue, not a bug > >>> really... Does that make sense? > >> Yes. > >> > >> Linux has always been a moving target and in very many circumstances > >> this has been A Good Idea! > >> I guess I'm too much old school and try to keep to the principle of > >> least surprise. > > > > I added some docs about this to this PR: > > > > https://github.com/systemd/systemd/pull/12686 > > > > ptal! > > ... and in the section about SyscallErrorNumber, there is a duplicate > remark: > > See (see project='man-pages'>errno3 > for a full list) for a full list of error codes. > > ... unless this is somehow mangled by the documetation builder. I fixed both issues now, and submitted as new PR: https://github.com/systemd/systemd/pull/12847 (btw, please always add review comments to the github PR rather than the mailing list, it's a lot easier to keep track of for us, and remember what is cared for already and what not) ptal, thanks, Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delegate v1 cgroup controller permissions
On Mi, 19.06.19 17:33, John Lane (syst...@jelmail.com) wrote: > > I have a service which runs as an unprivileged user (User=foo) with > delegated cgroup (Delegate=true) that wants to use the "memory" and > "cpu" controllers. Systemd is using the hybrid mode with both v1 and v2 > cgroups, and the controllers are assigned to the v1 groups. > > Before I can use the "cpu" or "memory" cgroups I have to force the > permissions of them because the delegated permissions are only applied > in the unified hierarchy. > > Doing this requires root which is a problem because we don't want to > give this service root permissions. > > I have read https://systemd.io/CGROUP_DELEGATION and note that the > hybrid mode "is a stopgap" and "has no future" but I am forced to use it > because the distros that we have to use (fedora) are set up that way (I > have yet to see any system use the unified v2 mode exclusively). So I'm > having to bother with hybrid mode even though I don't have enough free > time ;) > > I have read in the same article that delegation "won’t pass ownership of > the legacy controller hierarchies" and "think twice before delegating > cgroup v1 controllers to less privileged containers." > > I get that it isn't the preferred mechanism with systemd but we just > want to manage access to resources (cpu and memory) allocated to > subtasks from within our application. > > So is there a way to tell systemd (or some other way) to set the v1 > cgroup permissions so they are usable by the delegated user without > having to give the user process root privileges ? Sorry, but there is not, it's not safe, as documented. You are of course welcome to ignore that it's not safe, and chmod away anyway, but you are on your own if you do, we don't provide any functionality to do that for you, sorry! (And this not going to change anymore, cgroupsv1 is on its way out, and in cgroupsv2 all this is safe and you get access to the controllers as much as you want already) Sorry, Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allocating resource to achieve predictable run times
Hi. On Mon, Jun 17, 2019 at 02:15:19PM +0100, John Lane wrote: > I am trying to meet a requirement to have predictable execution of jobs. > [...] > When I say "container" I mean "an environment with reserved resources". > I have been looking at using cgroups both directly and via systemd. > [...] Do you have control over what jobs are you running? Or do you wish to have the predictable times for any kind of job (i.e. using any potentially shareable resource)? > Observations with a simple single-threaded test on one cpu: > [...] but I cannot get predictable results: that 1 job or n jobs take > the same amount of time. Ignoring the last outlier, how do the previous measurements miss your expectations? Michal (P.S. I can't tell from the public archive if I got the thread completely or if some messages weren't delivered so I may be behind or missing already presented context.) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
