On 2018-09-02 16:55:49 (+0200), Fons Adriaensen wrote: > On Sun, Sep 02, 2018 at 01:59:46PM +0200, David Runge wrote: > > > .... The use of the plain /etc/security/limits.conf > > is discouraged over the use of drop-in files in /etc/security/limits.d > > anyways! Please use those! > > Well, I have mixed feelings about these 'drop-in' directories which > seem to pop up everywhere. They may be very convenient for 'vendors' > (the one who introduced that concept to Linux should be shot) but > they are are a security nightmare for the local admin. Instead of > having to check one file which defines some policy, you now have > to check a whole collection every time some 'vendor' could have > 'dropped' something. Somehow this reminds me of dogs. Well, I guess you should've started complaining about that many years ago then ;-) That change/ addition has been around for a long time! Dropin files are not only convenient for vendors, but for distributions and their packagers alike. > Take systemd's logind. You have to verify a config file and *three* > directories in order to have any idea of how things are configured > in the end. And oh, yes, you can override everything in /etc. But > that effectively means you need to opt out of whatever some 'vendor' > pushes down your throat. Not once, but everytime you update. I see no problem in them. If you don't like them, you can start rolling your own distro without them ;-) Given the fact, that (at least with logind directly) on Arch there are absolutely no dropin files included, this is somewhat of a moot point you're bringing up btw. Besides: A setup like that gives the maximum amount of flexibility, which is what Linux is all about. As Arch is not Ubuntu, there's usually also no crazy amount of meta-layer configuration involved. > Re. this 'realtime' group: I don't like that either. Groups define Well, you're not here to like everything. I also don't like a few packages I work on. I deal with them nonetheless ;-) > a set of users with common needs. So *all* features or permissions > that members of a group need should be made dependent on being a > member of that group and nothing else. This is entirely the opposite > of defining groups for one particular feature such as real time and > then requiring users to be a member of all of them. I don't exactly understand your logic here: Members of the realtime group *share* the same common needs. They ought to be able to acquire realtime scheduling for their processes. Members of other groups don't. Members of the audio group have access to certain devices (users not in that group don't). So, I'm unsure, what you're actually complaining about here. Should this be set for every user separately (you're completely free to do so)? The realtime group is merely a convenience layer to have a shared group, that these settings are bound to. You're entirely free to do whatever you want with pam limits. In fact, if you dislike the realtime group so much, you don't even have to install the realtime-privileges package! You can just set this up in /etc/security/limits.conf all by yourself. Noone stops you from doing that. > For what it's worth, I noticed that after upgrading to kernel 4.18 I > had to increase the memlock limit to avoid error messages almost all > audio applications. With what exact setup is that? Which components are involved? How do you configure your users and limits? Are you using the realtime-privileges group? Is your user in the realtime group? Ask a specific question and we'll try to give a specific answer. Best, David -- https://sleepmap.de
Attachment:
signature.asc
Description: PGP signature
