bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[muradm]

Hi Maxim,

Maxim Cournoyer  writes:


Hi muradm,

muradm  writes:

[...]

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?


I didn't mean to imply that it didn't work; I just thought that 
it was
somehow bypassing PAM (and the original problem it caused in the 
first
place).  As I wrote earlier, I know next to nothing about PAM, 
and

misread your patch.

I've now installed the change.  Thanks for the fix, and thanks 
to

Ricardo for the reminder.


Cool, thanks!


signature.asc
Description: PGP signature

bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[muradm]

Hello,

Maxim Cournoyer  writes:


Hi,

muradm  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?


signature.asc
Description: PGP signature

bug#63198: [PATCH] services: cups: Add cups PAM service.

[muradm]

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.
[allow-empty-password?]: PAM service configuration permitting empty passwords.
(opaque-cups-configuration): Likewise.
(cups-pam-service): cups PAM service.
(cups-service-type): Extend pam-root-service-type with cups-pam-service.
---
 gnu/services/cups.scm | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/gnu/services/cups.scm b/gnu/services/cups.scm
index c6099d77e7..d95c38b4d9 100644
--- a/gnu/services/cups.scm
+++ b/gnu/services/cups.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2019 Alex Griffin 
 ;;; Copyright © 2019 Tobias Geerinckx-Rice 
 ;;; Copyright © 2021 Maxime Devos 
+;;; Copyright © 2023 muradm 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -25,6 +26,7 @@ (define-module (gnu services cups)
   #:use-module (gnu services)
   #:use-module (gnu services shepherd)
   #:use-module (gnu services configuration)
+  #:use-module (gnu system pam)
   #:use-module (gnu system shadow)
   #:use-module (gnu packages admin)
   #:use-module (gnu packages cups)
@@ -500,8 +502,11 @@ (define (serialize-package-list field-name val)
 
 (define-configuration cups-configuration
   (cups
-   (file-like cups-minimal)
+   (file-like cups)
"The CUPS package.")
+  (allow-empty-password?
+   (boolean #f)
+   "Specifies whether empty passwords will be allowed when authenticating via 
PAM.")
   (extensions
(package-list (list brlaser cups-filters epson-inkjet-printer-escpr
foomatic-filters hplip-minimal splix))
@@ -841,8 +846,11 @@ (define-configuration cups-configuration
 
 (define-configuration opaque-cups-configuration
   (cups
-   (package cups-minimal)
+   (package cups)
"The CUPS package.")
+  (allow-empty-password?
+   (boolean #f)
+   "Specifies whether empty passwords will be allowed when authenticating via 
PAM.")
   (extensions
(package-list '())
"Drivers and other extensions to the CUPS package.")
@@ -1006,6 +1014,14 @@ (define (cups-shepherd-service config)
"-f" "-c" #$cupsd.conf "-s" #$cups-files.conf)))
(stop #~(make-kill-destructor))
 
+(define (cups-pam-service config)
+  (let ((allow-empty-password?
+ (if (opaque-cups-configuration? config)
+ (opaque-cups-configuration-allow-empty-password? config)
+ (cups-configuration-allow-empty-password? config
+(list (unix-pam-service "cups"
+#:allow-empty-passwords? allow-empty-password?
+
 (define cups-service-type
   (service-type (name 'cups)
 (extensions
@@ -1013,6 +1029,8 @@ (define cups-service-type
   cups-shepherd-service)
(service-extension activation-service-type
   (const %cups-activation))
+   (service-extension pam-root-service-type
+  cups-pam-service)
(service-extension account-service-type
   (const %cups-accounts
 

base-commit: ed1e7920393c9ae5b2ae31fc46bae88136239b13
-- 
2.40.1

bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[muradm]

This change broke cups for me like this:

--8<---cut here---start->8---
I [13/May/2023:16:14:27 +0300] [Client 16] Started 
"/gnu/store/9kdm8k84j2xqlax4zaarchw00cfs62zz-cups-server-bin/lib/cups/daemon/cups-deviced" 
(pid=21409, file=14)
E [13/May/2023:16:14:27 +0300] [CGI] cups-brf must be called as 
root
E [13/May/2023:16:14:27 +0300] [cups-deviced] PID 21419 (cups-brf) 
stopped with status 1!
E [13/May/2023:16:14:27 +0300] [CGI] Unable to execute ippfind 
utility: No such file or directory
E [13/May/2023:16:14:27 +0300] [cups-deviced] PID 21421 
(driverless-fax) stopped with status 127!

--8<---cut here---end--->8---

cups-minimal does not include ippfind utility.

Normally, user whishing to use cups, should be in lp group, isn't 
it?

Maybe that was your original issue?

muradm  writes:


[[PGP Signed Part:Undecided]]

Could you please elaborate more on "loop on authenticating my 
user"

from above and "prevents users from authenticating" from commit
message? Does it mean that you could not authenticate as your 
user
at all, or does it relates to authentication at 
http://localhost:631

for managing printers?

[[End of PGP Signed Part]]




signature.asc
Description: PGP signature

bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[muradm]

Could you please elaborate more on "loop on authenticating my 
user"

from above and "prevents users from authenticating" from commit
message? Does it mean that you could not authenticate as your user
at all, or does it relates to authentication at 
http://localhost:631

for managing printers?


signature.asc
Description: PGP signature

bug#57748: swaylock broken since last commit

[muradm]

Hi,

swaylock needs wayland-protocols-next in native inputs
to compile.

wayland-protocols is 1.23, but new swaylock wants >= 1.25

Thanks in advance,
muradm


signature.asc
Description: PGP signature

bug#57642: [PATCH] gnu: linux: Fix unnecessary let clause in make-linux-libre.

[muradm]

* gnu/packages/linux.scm (make-linux-libre*)[arguments]:
Remove unnecessary let clause in 'configure phase.
---
 gnu/packages/linux.scm | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index f4880f164c..ee6e592183 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -852,8 +852,7 @@ (define* (make-linux-libre* version gnu-revision source 
supported-systems
#$(and extra-version
   (string-append "-" extra-version)))
 
-   (let ((build  (assoc-ref %standard-phases 'build))
- (config (assoc-ref inputs "kconfig")))
+   (let ((config (assoc-ref inputs "kconfig")))
 
  ;; Use a custom kernel configuration file or a default
  ;; configuration file.
-- 
2.37.2

bug#56971: greeter user permissions are not enough to talk with seatd

[muradm]

Liliana Marie Prikler  writes:


Am Donnerstag, dem 04.08.2022 um 15:52 +0300 schrieb muradm:


Liliana Marie Prikler  writes:

> [...] [L]ooking at the two patches, it appears they are to
> be used in combination?
>
No, technically they are not strongly dependent on each other,
could be applied one after another in no particular order.
After both are applied, in cooperation they address this issue.

This is what I'm saying, albeit in different words.  As far as I
understand, neither of these patches really accomplishes 
anything if

not put together.  Thus, you more or less opened three issues to
address one.

Really I don't know what to comment here else. My analysis showed
two independent issues, one is that seatd should have a declared
group so that users of it could join it. This issues is not 
specific

to greetd/greeter in any way. Any other greeting mechanism could
fall short on this. And second, greeter today required conditional
group to interact with seatd, or it could be any other group like
input, usb, modem or else depending on user setup.
Solutions are offered accordingly. Third issue, this bug I was
asked to open. I don't understand, is it a sin to have multiple
issues, or what is the problem here?




>
seatd it self has to run as root.

Okay.


That TODO is from the initial commit, it is about cgroup file
system mounting, and totally out of scope of this issue.
I didn't mean your code, I meant a suggestion from a reviewer 
that you

haven't addressed yet (to my knowledge at least).

done



Cheers




signature.asc
Description: PGP signature

bug#56971: greeter user permissions are not enough to talk with seatd

[muradm]

Liliana Marie Prikler  writes:


block 56971 by 56690 56699
thanks

Hi muradm,

Hi Liliana,


Am Donnerstag, dem 04.08.2022 um 12:45 +0300 schrieb muradm:

[...] greeter (e.g. gtkgreet) requiring communication
with seatd is failing to start, causing "black screen"
behavior on active terminal (switching to the other non seatd
related terminal is possible, for manual permissions
adjustment as workaround).

To address this issue, we need more flexible control over
seatd user/group, which creates seatd.sock, and greeter user
which connects to seatd.sock.

Okay.


However, not all greeters require that, so I decided to make
more flexible.
Flexibility for its own sake is not always the right solution. 
On the
other hand, looking at the two patches, it appears they are to 
be used

in combination?


No, technically they are not strongly dependent on each other,
could be applied one after another in no particular order.
After both are applied, in cooperation they address this issue.


 Propsed solutions consists of:

* 56690 - gnu: seatd-service-type: Should use seat group.
With this change, if seatd-service-type is present in the
system configuration, "seat" group will be added, and seatd
will run as root/seat. Group is configurable, but default is
"seat".
Why just the group and no user?  Is it not possible to launch 
seatd as

non-root?
seatd provides a way for display servers to access input/output 
devices

without having to be root. So seatd it self has to run as root.
When seatd opening socket as root/seat, all members of seat would
be able to communicate with it. Also socket could be opened with
seat/seat for instance, but there is no specific point in doing 
so.

Will be one more unused system user around.
Arch seems to follow similar way, root/seat is ok for socket.
Also will signal that seatd is running as root.


* 56699 - gnu: greetd-service-type: Add greeter-extra-groups
  config field.
With this change, if user wants to use seatd-service-type with
greeter requiring seatd.sock, he can add "seat" group to
greeter-extra-groups field.

Note that you still have a TODO on that patch.

That TODO is from the initial commit, it is about cgroup file
system mounting, and totally out of scope of this issue.


Cheers

Thanks in advance



signature.asc
Description: PGP signature

bug#56971: greeter user permissions are not enough to talk with seatd

[muradm]

Hi,

As per discussion here:
https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00020.html

Above change reduced permissions of greeter user.
While it is ok for greeters that do not talk to seatd,
greeters talking to seatd lost access to seatd socket.
As result, greeter (e.g. gtkgreet) requiring communication
with seatd is failing to start, causing "black screen"
behavior on active terminal (switching to the other non seatd
related terminal is possible, for manual permissions
adjustment as workaround).

To address this issue, we need more flexible control over
seatd user/group, which creates seatd.sock, and greeter user
which connects to seatd.sock.

Other distros (Arch for instance) introduced "seat" group.
So user which wants to login on system controlled by seatd
should be member of that group.

However, not all greeters require that, so I decided to make
more flexible. Propsed solutions consists of:

* 56690 - gnu: seatd-service-type: Should use seat group.
With this change, if seatd-service-type is present in the
system configuration, "seat" group will be added, and seatd
will run as root/seat. Group is configurable, but default is 
"seat".


* 56699 - gnu: greetd-service-type: Add greeter-extra-groups 
 config field.

With this change, if user wants to use seatd-service-type with
greeter requiring seatd.sock, he can add "seat" group to
greeter-extra-groups field.

Thanks in advance,
muradm



signature.asc
Description: PGP signature

bug#50604: [core-updates-frozen] make check-system tests broken

[muradm]

Hi,

Currently execution of any system tests with "make check-system 
..." seems
to be broken. Tests are getting executed, and their status is 
"pass" in
the log. But, some in some place around the test execution, below 
exception

is fired.

--8<---cut here---start->8---
This is the GNU system.  Welcome.
komputilo login: shepherd: changing HTTP/HTTPS proxy of 
'guix-daemon' to "http://localhost:8118;...

shepherd: Service guix-daemon has been stopped.
shepherd: Service guix-daemon has been started.
shepherd: clearing HTTP/HTTPS proxy of 'guix-daemon'...
shepherd: Service guix-daemon has been stopped.
shepherd: Service guix-daemon has been started.
Backtrace:
  4 (primitive-load 
  "/gnu/store/638i01a9gj6zknrcyp78n9pc434?")

In ice-9/eval.scm:
  191:35  3 (_ #f)
  196:35  2 (_ #f)
   263:9  1 (_ #(#(#) #f))
   155:9  0 (_ _)

ice-9/eval.scm:155:9: In procedure struct-vtable: Wrong type 
argument in position 1 (expecting struct): #f

QEMU runs as PID 10
connected to QEMU's monitor
read QEMU monitor prompt
connected to guest REPL
 Starting test basic  (Writing full log to "basic.log")
marionette is ready

;;; (services (console-font-tty2 user-homes mcron term-tty4 udev 
   term-tty2 syslogd console-font-tty5 user-processes 
   console-font-tty6 file-system-/sys/firmware/efi/efivars 
   loopback)

# of expected passes  27
# of skipped tests1
note: keeping build directory `/tmp/guix-build-basic.drv-1'
builder for 
`/gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv' failed 
with exit code 1
build of /gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv 
failed
View build log at 
'/var/log/guix/drvs/2r/k2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv.bz2'.
guix build: error: build of 
`/gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv' failed

make: *** [Makefile:7039: check-system] Error 1
--8<---cut here---end--->8---

Thanks in advance,
muradm

bug#44898: [wishlist] Make the GRUB installation procedure smarter

[muradm]

First I was using Guix on Lenovo Carbon X1 in parallel with Arch. 
Few times I experiences "NVRAM full" or similar problem, I don't 
recall now. Solution was to reset NVRAM by some procedure. Half a 
year now, I moved to System76 Lemur Pro, where I have only Guix 
alone. Here I have another problem, sometimes it simply does not 
boot, then I have to plug USB, and run grub-install manually to 
recover.


As per discussion on IRC today, I would suggest the folowing 
regarding grub efi, I'm not using other bootloaders, but I suppose 
same logic may apply.


There are two things about grub:

1) /boot/efi/EFI/Guix/grubx64.efi & NVRAM - these are changing 
very very rarely, only when grub version change, boot partition 
change.


2) /boot/grub/* - these are changing only when grub version change 
or new guix generation is created, then grub.cfg is getting 
updated.


Currently, as far as I understand, both of them are getting 
installed with one script from this derivation:

/gnu/store/...-install-bootloader.scm.drv

It could be split into two, one which runs grub-install, i.e. #1 
above, the other which covers #2 above, let's say 
bootloader-phase-1-install and bootloader-phase-2-install 
respectively.


Then, each script can be executed only when derivation is 
changing. With the following exceptions:

- must be executed anyway on "guix system init ..."
- must be executed only if "guix system reconfigure 
 --force-bootloader ..."


Scripts them selves store grub version (via absolute path), thus 
if grub updated, derivations will change.


If for some reason, grub and/or nvram getting broken on boot, user 
has to boot with some kind recovery media anyway.

bug#49990: [PATCH] gnu: Fix classpath-bootstrap compilation

[muradm]

This patch fixes issue in the way that it:
a) calculates the result before call to 
(*env)->ReleaseStringUTFChars

b) attempt to trick gcc optimizations by complicating path

I suppose issue is with what (*env)->ReleaseStringUTFChars does 
and

how.

One should note that similar approach is not applicable to 
substitute

in package definition.

Why not just build ancient code with ancient gcc?

bug#49990: [PATCH] gnu: Fix classpath-bootstrap compilation

[muradm]

---
 gnu/packages/java.scm |  3 +-
 .../patches/classpath-instruction-order.patch | 35 +++
 2 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/classpath-instruction-order.patch

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 08ef7a8213..1e29cac401 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -230,7 +230,8 @@ only faster.")
   (sha256
(base32
 "0i99wf9xd3hw1sj2sazychb9prx8nadxh2clgvk3zlmb28v0jbfz"))
-  (patches (search-patches "classpath-aarch64-support.patch"
+  (patches (search-patches "classpath-aarch64-support.patch"
+   "classpath-instruction-order.patch"
 (build-system gnu-build-system)
 (arguments
  `(#:configure-flags
diff --git a/gnu/packages/patches/classpath-instruction-order.patch 
b/gnu/packages/patches/classpath-instruction-order.patch
new file mode 100644
index 00..278ae912c7
--- /dev/null
+++ b/gnu/packages/patches/classpath-instruction-order.patch
@@ -0,0 +1,35 @@
+diff -ruN ../classpath/classpath-0.93/native/jni/java-io/java_io_VMFile.c 
./native/jni/java-io/java_io_VMFile.c
+--- ../classpath/classpath-0.93/native/jni/java-io/java_io_VMFile.c
2006-09-23 08:17:45.0 +0300
 ./native/jni/java-io/java_io_VMFile.c  2021-09-03 01:08:17.073644627 
+0300
+@@ -278,6 +278,7 @@
+   const char *filename;
+   int result;
+   jint entryType;
++  int fres;
+ 
+   /* Don't use the JCL convert function because it throws an exception
+  on failure */
+@@ -288,9 +289,22 @@
+ }
+ 
+   result = cpio_checkType (filename, );
++
++  fres = 1;
++
++  if (result != CPNATIVE_OK)
++{
++  fres = 0;
++}
++
++  if (entryType != CPFILE_FILE)
++{
++  fres = 0;
++}
++
+   (*env)->ReleaseStringUTFChars (env, name, filename);
+ 
+-  return result == CPNATIVE_OK && entryType == CPFILE_FILE ? 1 : 0;
++  return fres;
+ #else /* not WITHOUT_FILESYSTEM */
+   return 0;
+ #endif /* not WITHOUT_FILESYSTEM */
-- 
2.33.0

bug#50193: guix: shepherd pid 1 holds /dev/console

[muradm]

On IRC chat we identified an issue related to linux SAK, which
is explained here 
https://www.kernel.org/doc/html/latest/security/sak.html


Following the check what processes will be SAK'ed:

~# ls -l /proc/[0-9]*/fd/* | grep console
lrwx-- 1 root   root   64 Aug 24 21:22 /proc/1/fd/1 -> 
/dev/console
lrwx-- 1 root   root   64 Aug 24 21:22 /proc/1/fd/2 -> 
/dev/console
l-wx-- 1 root   root   64 Aug 24 21:22 /proc/578/fd/4 -> 
/dev/console
lrwx-- 1 root   root   64 Aug 24 21:22 /proc/593/fd/1 -> 
/dev/console
lrwx-- 1 root   root   64 Aug 24 21:22 /proc/593/fd/2 -> 
/dev/console
lrwx-- 1 root   root   64 Aug 24 20:03 /proc/705/fd/1 -> 
/dev/console
lrwx-- 1 root   root   64 Aug 24 20:03 /proc/705/fd/2 -> 
/dev/console
lrwx-- 1 root   root   64 Aug 24 21:22 /proc/909/fd/1 -> 
/dev/console
lrwx-- 1 root   root   64 Aug 24 21:22 /proc/909/fd/2 -> 
/dev/console


As it is seen from above output, pid 1 which is shepherd holds 
/dev/console
making linux SAK feature useless. When SAK command issued by 
shortcut keys,
all above proceses gets killed including pid 1 which is shepherd, 
causing

system to stall.

bug#49771: conflicting pam-limits-service and pam-mount-service-type

[muradm]

pam-limits-service and pam-mount-service-type are working when 
used only one of them. When both are present in list of (services, 
conflict hapens when guix system reconfigure is invoked. Digging 
the problem led to use of etc-service-type.


pam-limits-service defines /etc/security/limits.conf in 
gnu/services/base.scm:


(define pam-limits-service-type
 (let ((security-limits
;; Create /etc/security containing the provided 
"limits.conf" file.

(lambda (limits-file)
  `(("security"
 ,(computed-file
   "security"
   #~(begin
   (mkdir #$output)
   (stat #$limits-file)
   (symlink #$limits-file
(string-append #$output "/limits.conf"
   (pam-extension
(lambda (pam)

Basically, it says to etc-service-type i need "security" under 
"/etc" and uses mkdir to create it.


pam-mount-service-type asks "security/pam_mount.conf.xml" from 
etc-service-type.


(define (pam-mount-etc-service config)
 `(("security/pam_mount.conf.xml"
,(make-pam-mount-configuration-file config

When both pam-mount-service-type and pam-limits-service are 
defined in (services ...), if pam-mount-service-type is before 
pam-limits, guix system reconfigure fails with "Permission 
denied", if pam-limits is before then it is "File exists".


I would suggest to fix gnu/services/base.scm so that 
pam-limits-services-type ask for "security/limits.conf" just like 
pam-mount-services-type does in order to avoid conflict.


Currently, both pam-limits-service and pam-mount-service-type are 
not usable at the same time.