From: muradm <mail@muradm.net>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 63198@debbugs.gnu.org
Subject: bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication
Date: Tue, 16 May 2023 08:17:56 +0300 [thread overview]
Message-ID: <87edngon5j.fsf@muradm.net> (raw)
In-Reply-To: <877ct9vcrg.fsf_-_@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]
Hello,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Hi,
>
> muradm <mail@muradm.net> writes:
>
>> Fixes <https://issues.guix.gnu.org/63198>.
>>
>> Makes CUPS service to extend pam-root-service-type providing
>> minimal
>> configuration to authenticate users. Since PAM authentication
>> is
>> provided, cups package can be used as default.
>>
>> * gnu/services/cups.scm (cups-configuration) [cups]: Use cups.
>
> I'd write 'Replace cups-minimal with cups'.
>
Sure you may change this.
>> [allow-empty-password?]: PAM service configuration permitting
>> empty passwords.
>
> I'd write 'New field', but I think we'd want to add proper PAM
> support
> here not a 'bypass PAM authentication' hack. It should also be
> enabled
> out of the box, otherwise users won't be able to authenticate
> until they
> figure out they need to set that switch to #t.
>
Who ever touches PAM configuration knows that by default PAM does
not
allow to authenticate users with empty passwords. This flag allows
such
users. Just grep guix for allow-empty-password?, you will see that
it
is all over the places.
>> (opaque-cups-configuration): Likewise.
>> (cups-pam-service): cups PAM service.
>
> Not descriptive :-) What is the change here?
>
I used simlilar strategy as in your commit 6bc3e3f9ba :-) You are
free
to reword as you wish.
> Could you look into adding "regular" login PAM support instead
> of a
> bypass disabled by default? The user should still be prompted
> for its
> password, and it should go through the PAM auth module.
>
> I'm not very PAM-aware, but I believe there are examples spread
> in the
> code base.
This patch provides necessary configuration for proper PAM
support.
I decided to take screen-locker-service-type's configuration as
basis, since it is was most simpliest and adequate enough for this
case.
This patch does not disables, baypasses or cheats PAM in any way.
User may navigate to CUPS portal. In the event of administrative
actions taken by user, CUPS portal asks user to authenticate.
With this configuration, it will attempt to authenticate as local
system user. In the event of proper system user/password supplied
and positively authenticated against PAM using "cups" service
name,
user allowed to take administrative action. In the event of
invalid
system user/password supplied, CUPS portal will keep looping
begging for password (just as in your original case). If user
decides
to Cancel the authentication dialog, CUPS portal is navigated to
Unauthorized access informing page.
Why would I submit something that it is not working?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2023-05-16 5:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-01 3:08 bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication Maxim Cournoyer
2023-05-03 12:46 ` Maxim Cournoyer
2023-05-13 13:43 ` muradm
2023-05-13 13:48 ` muradm
2023-05-15 15:13 ` Maxim Cournoyer
2023-05-15 15:12 ` Maxim Cournoyer
2023-05-13 18:38 ` bug#63198: [PATCH] services: cups: Add cups PAM service muradm
2023-05-15 15:24 ` bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication Maxim Cournoyer
2023-05-16 5:17 ` muradm [this message]
2023-05-24 0:46 ` Maxim Cournoyer
2023-05-24 11:37 ` muradm
2023-05-23 22:14 ` Ricardo Wurmus
2023-05-24 11:07 ` bug#63198: End-to-end tests Was: " Csepp
2023-05-24 11:28 ` muradm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87edngon5j.fsf@muradm.net \
--to=mail@muradm.net \
--cc=63198@debbugs.gnu.org \
--cc=maxim.cournoyer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.