From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:43332) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFg0x-0006a2-BB for guix-patches@gnu.org; Wed, 02 Oct 2019 10:54:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iFg0w-0001Ve-6H for guix-patches@gnu.org; Wed, 02 Oct 2019 10:54:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:57544) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iFg0w-0001Va-2e for guix-patches@gnu.org; Wed, 02 Oct 2019 10:54:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iFg0v-0008Bd-UC for guix-patches@gnu.org; Wed, 02 Oct 2019 10:54:01 -0400 Subject: [bug#37405] [PATCH] Services: Check and modify gdm-password in pam-limits Resent-Message-ID: Message-ID: From: Jesse Gibbons In-Reply-To: <20191002010032.1f01e2b0@scratchpost.org> References: <14cd3e26c2dae4de79a2bc87fb8614c8f737e629.camel@gmail.com> <461364c376c0c54f0bfff80ed7727d182400671f.camel@gmail.com> <20191002010032.1f01e2b0@scratchpost.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Oct 2019 08:53:24 -0600 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Danny Milosavljevic Cc: 37405@debbugs.gnu.org On Wed, 2019-10-02 at 01:00 +0200, Danny Milosavljevic wrote: > Hi, > > thanks for the patch. > > I'm not thrilled about that approach (arguably Guix already does it wrong > anyway). I think you should start a thread on the guix-devel list expressing your concerns, and we can discuss how to improve guix from there. > > But since the manual of pam_limits does describe that one should use it > like that, I have applied it as a stop-gap fix to guix master as > commit 0bf7d34d77ffca40be9e04586195054e9f2c7a13. Thanks! > > Long term, we should really make pam entries first class and show up in > the > operating-system record--that's what they are FOR: to let the > administrator > (and thus the organization) choose how they want to do user > authorization/session handling etc. If PAM configurations should be up to the administrator, there should be documentation to teach the administrator how to use them. The manual doesn't say anything about how to use pam-services in operating-system, so I submitted a bug report (bug #37583) requesting documentation. > Why do we decide for them? I think I agree with your point that if a non-default configuration is desired, administrators should be able to modify it, just like any other part of the configuration. Ideally they can always opt-out of details they don't want. I do not agree that we are deciding for the admins. This is just like the discussion about whether GuixSD should include the /usr/bin/env and /bin/sh special files by default, except there isn't any documentation on how to opt out of or extend the default PAM services. There must be a default for every detail. If a detail is found practical most of the time, I think it is good to either have it as a default (like /usr/bin/sh) or have a ready example of how to implement it viewable from the install environment (like what we do with desktop environments) so most users don't have to look up how to add it. That does not negate the ability of power users and administrators to opt out in the operating-system configuration. In the context of this patch, pam-limits is still opt-in. Perhaps a more flexible fix would be to make the pam-limits-service-type accept an optional list of strings identifying the configurations to create or modify to use pam-limits, with the default being %default-pam-limits-service-names defined as '("login" "su") which could then be appended to %slim-pam- service-names '("slim") or %gdm-pam-service-names '("gdm-password" ...). If you or anyone else wants to implement that proposal and update the documentation so admins will know how to configure it, feel free. I hope I did not misunderstand your comments. We can discuss this and your other concerns in a guix-devel thread. -- -Jesse