我有一个 systemd 用户服务,需要访问一个 Unix 组拥有的文件夹,而该文件夹位于另一个 Unix 组拥有的另一个文件夹中。“其他”甚至没有读取权限。systemd 服务的用户是这两个组的成员,通常可以访问此文件夹。但是,systemd 服务似乎只具有其中一个组的权限。我尝试了服务文件中的 Group= 配置,但它不允许我同时选择多个组。
我如何从 systemd 服务内部访问这些文件?
更新:
SupplementaryGroups= 设置(由 JayEye 建议)在大多数情况下可能是正确的答案,但它对我的情况不起作用。我得到
Failed at step GROUP spawning ..... : Operation not permitted
我看到“/lib/systemd/systemd --user”进程本身只在一个组中运行。也许事情变得复杂的是,我的设置中的组成员身份是通过 LDAP 提供的,而不是在 /etc/group 中设置的?
答案1
https://freedesktop.org/software/systemd/man/systemd.exec.html#SupplementaryGroups
例子:
[Unit]
Description=Foobar service
After=network.target
[Service]
Type=oneshot
RemainAfterExit=no
PrivateTmp=false
WorkingDirectory=/tmp
SupplementaryGroups=0 1 adm
ExecStart=/bin/bash -c 'groups >> /tmp/foobargroups'
ExecReload=/bin/bash -c 'groups >> /tmp/foobargroups'
[Install]
WantedBy=multi-user.target
启动它;然后你会看到root daemon adm
/tmp/foobargroups
答案2
启动计算机时,在从 LDAP 服务器接收组成员信息之前,systemd 用户守护程序会启动(通过延迟)。此时,会检查 /etc/group 中的组成员身份。因此,修复方法很简单:还必须在本地计算机上的 /etc/group 中将用户添加到额外的组中。
因此,如果您在机器上具有 root 访问权限,请将其添加到 /etc/group 底部,供每个需要的额外组使用,然后重新启动计算机:
mygroup:x:mygid:myuser
重要的是,mygid 与 LDAP 服务器给出的相同 GID(组标识符)相匹配。
在这种情况下,SupplementaryGroups= 实际上是没有必要的。
(如果没有问题中提供的“更新:”,@JayEye 的回答(https://superuser.com/a/1588291/852516) 对于大多数回答这个问题的人来说可能都是正确的。