FS#56462 - [sddm] please create /var/lib/sddm under pacman

Attached to Project: Arch Linux
Opened by BrLi (brli) - Sunday, 26 November 2017, 15:31 GMT
Last edited by Antonio Rojas (arojas) - Tuesday, 28 November 2017, 11:33 GMT
Task Type General Gripe
Category Packages: Extra
Status Closed
Assigned To Antonio Rojas (arojas)
Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

there is the sysusers and tmpfiles configuration of the directory /var/lib/sddm

but it isn't part of the package, in fact, no package owns that directory.

please install -d -o -g -m it in PKGBUILD first, so that it is manageable by pacman.

Additional info:
* package version(s) 0.16.0
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Antonio Rojas (arojas)
Tuesday, 28 November 2017, 11:33 GMT
Reason for closing:  Won't implement
Additional comments about closing:  See comments. Unmanaged files/dirs under /var are fine, this is not going to have any real effect as the contents will still be unmanaged and it may give UID mismatch warnings in the future if we decide to give sddm a fixed UID.
Comment by Doug Newgard (Scimmia) - Sunday, 26 November 2017, 16:37 GMT
Why? AFAIK, this dir has never been managed by pacman.
Comment by loqs (loqs) - Sunday, 26 November 2017, 16:59 GMT
Even if pacman managed the directory the contents would still be unmanaged.
Comment by BrLi (brli) - Monday, 27 November 2017, 07:29 GMT
The other directories created by other packages under /var/lib are all managed by pacman (eg. alsa-utils, systemd, and pacman itself, to name but a few).

Yet, their contents are not managed by pacman, either.

As in https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s08.html describe how the directory and its subdirectories are used.

>This hierarchy holds state information pertaining to an application or the system.

To imagine this, it is like /home for system users(programs) to store their own data and should not be exposed to others.
Comment by loqs (loqs) - Monday, 27 November 2017, 12:09 GMT
/var/lib/alsa /var/lib/systemd and /var/lib/pacman are all owned root:root while /var/lib/sddm is owned sddm:sddm
so sddm would would need to have a uid and gid assigned so that the directory could be chowned correctly in the PKGBUILD.

As for all other directories under /var/lib being managed by pacman take /var/lib/libvirt/qemu provided by libvirt yes its managed by pacman
but because of kvm losing its gid it gets its ownership changed on the first run of libvirtd on a new install and dropping the directory from PKGBUILD would fix that.
Comment by BrLi (brli) - Monday, 27 November 2017, 13:28 GMT
@loqs: So, what is the point of those under /var/lib/ being managed by pacman have an ownership of root:root, or not?

I mean, it doesn't matter whatever their ownership, they *ARE* part of pacman's tree, where /var/lib/sddm currently isn't.

Besides, we have the sddm.sysusers and sddm.tmpfiles which define the generation and clean-up of the directory, I don't see a reason why it shouldn't be part of package.
Comment by loqs (loqs) - Monday, 27 November 2017, 15:38 GMT
What gid and uid would you add /var/lib/sddm with in the package? You would then rely tmpfiles to fix the ownership mismatch?
If so pacman -Qkk would flag the mismatch. If you assign sddm a uid and gid all existing installs with a sddm user and group would need manual intervention.
Are you also going to request /var/lib/machines be managed by pacman?
Comment by Doug Newgard (Scimmia) - Monday, 27 November 2017, 15:56 GMT
My point in asking why was trying to expand on the ticket. As it was filed, it just said "do this" with no rational or advantages given. So far, the only thing we've gotten is "everyone else does it", which isn't much of a reason.
Comment by BrLi (brli) - Monday, 27 November 2017, 15:59 GMT
sddm assigned itself to 996:996 by default in its source, so should /var/lib/sddm be, no?
about /var/lib/machines, maybe it should be installed root:root 700 in systemd package by default, too. But that should follow another ticket.

Comment by Eli Schwartz (eschwartz) - Monday, 27 November 2017, 19:40 GMT
The difference is that those other packages create empty directories via the upstream build system, and repo packages are not currently built with !emptydirs

I would feel more comfortable filing bugs against some of those packages which do provide those empty directories, asking them to migrate to tmpfiles instead. :p

Loading...