Bugzilla – Bug 1184161
VUL-0: CVE-2021-25317: cups: ownership of /var/log/cups could allow privilege escalation from lp user to root via symlink attacks
Last modified: 2024-05-23 15:31:16 UTC
I noticed that on Tumbleweed (and probably all other maintained cups codestreams) the /var/log/cups directory is packaged as follows: drwxr-xr-x 2 lp lp 4096 24. Mär 16:47 /var/log/cups/ This means the 'lp' user can perform arbitrary writes in this directory. The cups daemon is running as root, however, potentially creating log files in this directory. A simple reproducer is as follows: ``` root# sudo -u lp /bin/bash lp$ cd /var/log/cups lp$ rm -f * lp$ for log in error access page; do ln -s /root/${log}_log; done lp$ exit root# cupsctl --debug-logging ``` Interestingly, as a side effect of enabling cups logging, the ownership of /var/log/cups is changed. After the reproducer we get: drwxr-xr-x 2 root lp 4.0K 30. Mär 13:27 /var/log/cups/ The reason for this is cups itself in scheduler/log.c with the following invocation: ``` cupsdCheckPermissions(CUPS_LOGDIR, NULL, log_dir_perm, RunUser, Group, 1, -1); ``` This function makes sure that the log directory is owned by the RunUser and Group that cups is configured for. This can be too late already, however. Also after package updates of cups-config the original packaging permissions are reinstated. Other distributions like Arch, Debian and Gentoo package /var/log/cups with root:root ownership. Only Fedora suffers from the same issue as we do. So we might need to report this to them as well, although they should be protected by their SELinux configuration.
(In reply to jsmeix@suse.com from comment #1) > I am a noob with symlink attacks. > Could you provide a complete reproducer that actually does something > what only root can do after privilege escalation from lp to root > e.g. how lp could do "head -n1 /etc/shadow" or something like that. The reproducer in comment 0 should lead to empty files being created like /root/error_log. If not very familiar with when e.g. the access_log is filled with something by cupsd, this would probably the most interesting vector, more kind of a denial-of-service by writing garbage to system files. Since cups has a locally accessible web interface a local attacker could also influence the content of log files in some ways, so some sort of privilege escalation could also become possible. It is not super serious but we should fix it anyway. > permissions are set there as is. > I guess there is (or was?) some special reason for it > because otherwise no special permissions would be set. Probably rather "was". The security issue is only with the write permission for the lp user. So if there is no process running as 'lp' that needs to write there then there should be no issue. Since all other distributions except Fedora don't package with lp write permissions and since cupsd *itself* is "fixing" these permissions for /var/log/cups during runtime I don't think there is a big risk for breaking anything. > ----------------------------------------------------------- > # osc cat DISCONTINUED:openSUSE:10.3:Update cups cups.spec > ... > %files libs > %defattr(-,root,root) > %{_bindir}/cups-config > #%dir %attr(0755,lp,lp) %{_sysconfdir}/cups/ > %dir %attr(0710,lp,lp) %{_var}/spool/cups > %dir %attr(1770,lp,lp) %{_var}/spool/cups/tmp > %dir %attr(0755,lp,lp) %{_var}/log/cups/ > ----------------------------------------------------------- The write permission for lop for /spool/cups and /etc/cups is no longer there, which is good. Only for /var/log/cups and for the /var/spool/cups/tmp sticky bit directory. Hopefully cupsd does not create fixed paths in the latter, but at least symlink protection from the kernel would be kicking in here, because it is world-writable. > I will contact the Red Hat CUPS maintainer via personal mail. > Perhaps he knows more about the reason for such kind of > special permission settings. > > If needed we can also contact the CUPS author via personal mail > to find out what the nowadays right way is. Yes thanks for investigating.
Some tests with latest CUPS 2.3.3 from OBS Printing project: I tested normal printing with # rm -r /var/log/cups # mkdir /var/log/cups # ls -ld /var/log/cups drwxr-xr-x 2 root root 4096 Apr 7 11:40 /var/log/cups and for me it still works well - in particular the usual log messages from filters and backends appear in /var/log/cups/error_log as expected because filters and backends should write log messages to the inherited stderr file descriptor and not try to append them directly to /var/log/cups/error_log (via fopen on their own). How cupsd itself creates /var/log/cups # rm -r /var/log/cups # systemctl start cups.service # ls -ld /var/log/cups drwxr-xr-x 2 root lp 4096 Apr 7 11:57 /var/log/cups I think it is best to package /var/log/cups in the RPM with same owner:group and permissions as cupsd creates it. I don't know the reason why cupsd sets group 'lp' (cf. above plain printing also works for me with group 'root') but I guess there is a reason why the configure --with-cups-group=lp setting is used there i.e. why group 'lp' needs read permissions. We configure cups with (excerpts): --with-cups-user=lp --with-cups-group=lp --with-system-groups=root cf. our whole RPM cups.spec file at https://build.opensuse.org/package/view_file/Printing/cups/cups.spec?expand=1
Yes, using the permissions that cupsd sets makes the most sense, since it overrides them anyway sooner or later during runtime. Giving the lp group read access there seems reasonable to me. Please backport this change also for maintained cups codestreams. I will see to it that a SUSE-CVE is assigned for this issue.
Please use CVE-2021-25317 to track this
How cupsd in latest CUPS 2.3.3 from OBS Printing project creates directories: drwxr-xr-x 2 root lp ... /etc/cups/ppd drwx--x--- 3 root lp ... /var/spool/cups drwxrwx--T 2 root lp ... /var/spool/cups/tmp drwxr-xr-x 2 root lp ... /var/log/cups drwxrwx--- 3 root lp ... /var/cache/cups How we create those directories in our RPM cups.spec file: %dir %attr(755,root,lp) %{_sysconfdir}/cups/ppd %dir %attr(0710,root,lp) %{_var}/spool/cups %dir %attr(1770,root,lp) %{_var}/spool/cups/tmp %dir %attr(0755,lp,lp) %{_var}/log/cups/ %dir %attr(0775,lp,lp) %{_var}/cache/cups which results drwxr-xr-x 2 root lp ... /etc/cups/ppd drwx--x--- 3 root lp ... /var/spool/cups drwxrwx--T 2 root lp ... /var/spool/cups/tmp drwxr-xr-x 2 lp lp ... /var/log/cups drwxrwxr-x 2 lp lp ... /var/cache/cups so /var/log/cups and /var/cache/cups need to be adjusted according to how cupsd creates them. Regarding other directories that we create with special owner group and permission settings in our cups.spec file: %dir %attr(700,root,lp) %{_sysconfdir}/cups/ssl %dir %attr(0775,root,ntadmin) %{_datadir}/cups/drivers %dir %attr(0755,root,lp) /etc/cups Those directories are not created by cupsd. Regarding /etc/cups cupsd cannot start if there is no /etc/cups because cupsd needs a /etc/cups/cupsd.conf file and without it cupsd aborts with ------------------------------------------------------------------- # journalctl -xe ... linux-h9wr cupsd[8150]: Unable to open "/etc/cups/cupsd.conf" - No such file or directory ... linux-h9wr systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE ... linux-h9wr systemd[1]: Failed to start CUPS Scheduler. ------------------------------------------------------------------- I think drwxr-xr-x 6 root lp ... /etc/cups is OK. Regarding /usr/share/cups/drivers I don't know the reason for the 'ntadmin' group (at least there is such a group in /etc/group) so I hope drwxrwxr-x 2 root ntadmin ... /usr/share/cups/drivers is OK. Regarding /etc/cups/ssl: When it is missing ------------------------------------------------------------ # lpstat -E -p lpstat: Bad file descriptor ------------------------------------------------------------ so we need to create it. For me it works as follows (cf. https://bugzilla.suse.com/show_bug.cgi?id=1108444#c2) ------------------------------------------------------------ linux-h9wr:~ # mkdir -m 700 /etc/cups/ssl linux-h9wr:~ # lpstat -E -p printer ps is idle. enabled since Mon Mar 29 12:35:42 2021 linux-h9wr:~ # ls -ld /etc/cups/ssl drwx------ 2 root root ... /etc/cups/ssl linux-h9wr:~ # ls -l /etc/cups/ssl/* -rw-r--r-- 1 root root ... /etc/cups/ssl/linux-h9wr.crt -rw-r--r-- 1 root root ... /etc/cups/ssl/linux-h9wr.key ------------------------------------------------------------ In contrast we create it in our RPM as drwx------ 2 root lp ... /etc/cups/ssl with files in it like -rw-r--r-- 1 root root ... /etc/cups/ssl/linux-h9wr.crt -rw-r--r-- 1 root root ... /etc/cups/ssl/linux-h9wr.key I think it does not make sense to create a directory with group 'lp' but without any group permissions so I think we should create /etc/cups/ssl as %dir %attr(700,root,root) %{_sysconfdir}/cups/ssl
We now involved RedHat who also has the same issue in their packaging. We are currently negotiating a publication date for the finding. They seem to like a later date for this (latest date according to our policy is 2021-06-28). Please don't leak any information about this into OBS (including Factory) until the to-be-established publication date is reached. For IBS this means that updates can be submitted and processed but cannot be released before the publication date is reached. In updates please add the CVE number found in the bug summary to the changes file for reference.
How things are on SLE15 with CUPS 2.2.7: How we create directories via RPM: drwxr-xr-x 2 root lp 4096 Apr 6 2020 /etc/cups/ppd drwxrwxr-x 2 lp lp 4096 Apr 6 2020 /var/cache/cups drwxr-xr-x 2 lp lp 4096 Apr 6 2020 /var/log/cups drwx--x--- 3 root lp 4096 Feb 24 11:51 /var/spool/cups drwxrwx--T 2 root lp 4096 Apr 6 2020 /var/spool/cups/tmp drwx------ 2 root lp 4096 Apr 6 2020 /etc/cups/ssl/ How cupsd creates them: drwxr-xr-x 2 root lp 4096 Apr 12 10:16 /etc/cups/ppd drwxrwx--- 3 root lp 4096 Apr 12 10:17 /var/cache/cups drwxr-xr-x 2 root lp 4096 Apr 12 10:17 /var/log/cups drwx--x--- 3 root lp 4096 Apr 12 10:16 /var/spool/cups drwxrwx--T 2 root lp 4096 Apr 12 10:16 /var/spool/cups/tmp # lpstat -E -p also works on SLE15 with CUPS 2.2.7 with drwx------ 2 root root 4096 Apr 12 10:22 /etc/cups/ssl
How things are on SLE12 with CUPS 1.7.5: How we create directories via RPM: drwxr-xr-x 2 root lp 4096 Feb 27 2019 /etc/cups/ppd drwx--x--- 3 root lp 4096 Feb 25 10:10 /var/spool/cups drwxrwx--T 2 root lp 4096 Feb 27 2019 /var/spool/cups/tmp drwxr-xr-x 2 lp lp 4096 Feb 27 2019 /var/log/cups drwxrwxr-x 2 lp lp 4096 Feb 27 2019 /var/cache/cups drwx------ 2 root lp 4096 Feb 27 2019 /etc/cups/ssl How cupsd creates them: drwxr-xr-x 2 root lp 4096 Apr 12 13:22 /etc/cups/ppd drwx--x--- 3 root lp 4096 Apr 12 13:22 /var/spool/cups drwxrwx--T 2 root lp 4096 Apr 12 13:22 /var/spool/cups/tmp drwxr-xr-x 2 root lp 4096 Apr 12 13:21 /var/log/cups drwxrwxr-x 3 root lp 4096 Apr 12 13:22 /var/cache/cups # lpstat -E -p also works on SLE12 with CUPS 1.7.5 with # mkdir -m 700 /etc/cups/ssl drwx------ 2 root root 4096 Apr 12 13:22 /etc/cups/ssl where cupsd creates files in /etc/cups/ssl like -rw------- 1 root lp 1241 Apr 12 13:22 server.crt -rw------- 1 root lp 1704 Apr 12 13:22 server.key
How things are on SLE11 with CUPS 1.3.9: How we create directories via RPM: drwxr-xr-x 2 root lp 4096 May 27 2015 /etc/cups/ppd drwx--x--- 3 root lp 4096 Jun 9 2020 /var/spool/cups drwxrwx--T 2 root lp 4096 May 27 2015 /var/spool/cups/tmp drwxr-xr-x 2 lp lp 4096 May 27 2015 /var/log/cups drwxrwxr-x 2 lp lp 4096 May 27 2015 /var/cache/cups drwx------ 2 root lp 4096 May 27 2015 /etc/cups/ssl How cupsd creates them: drwxr-xr-x 2 root lp 4096 Apr 13 08:46 /etc/cups/ppd drwx--x--- 3 root lp 4096 Apr 13 08:46 /var/spool/cups drwxrwx--T 2 root lp 4096 Apr 13 08:46 /var/spool/cups/tmp drwxr-xr-x 2 root lp 4096 Apr 13 08:46 /var/log/cups cupsd does not create /var/cache/cups # lpstat -E -p also works on SLE11 with CUPS 1.3.9 with # mkdir -m 700 /etc/cups/ssl drwx------ 2 root root 4096 Apr 13 08:48 /etc/cups/ssl where cupsd creates files in /etc/cups/ssl like -rw------- 1 root lp 1013 Apr 13 08:48 server.crt -rw------- 1 root lp 887 Apr 13 08:48 server.key
On SLE11 with CUPS 1.3.9 cupsd does not create /var/cache/cups but it creates /etc/cups/yes instead drwxrwxr-x 3 root lp 4096 Apr 13 09:05 /etc/cups/yes because on SLE11 cups.spec contains configure ... --with-cachedir instead of what we have in SLE12 and later configure ... --with-cachedir=/var/cache/cups cf. in cups.changes ------------------------------------------------------------------- Wed Jan 27 14:43:37 CET 2010 - jsmeix@suse.de ... - Added the explicite path to '--with-cachedir=/var/cache/cups' in cups.spec to avoid that the fallback value 'yes' results the cache directory '/etc/cups/yes/'. ------------------------------------------------------------------- Because this issue here is not about /var/cache/cups and because the right owner group and permissions are set by cupsd for /etc/cups/yes and it works this way in SLE11 I will not introduce a not needed change here for SLE11.
How things are on SLE10 with CUPS 1.1.23: How the directories are after SL10-SP4 installation (in SLE10 cupsd gets started by default so cupsd is already running after SL10-SP4 installation): drwxr-xr-x 2 lp lp 48 2010-11-09 11:14 /etc/cups/ppd drwx--x--- 3 lp lp 72 2021-04-13 12:39 /var/spool/cups drwxrwx--T 2 lp lp 48 2010-11-09 11:14 /var/spool/cups/tmp drwxr-xr-x 2 lp lp 80 2021-04-13 12:45 /var/log/cups drwx------ 2 lp lp 48 2010-11-09 11:14 /etc/cups/ssl /var/cache/cups: No such file or directory /etc/cups/yes: No such file or directory Neither the CUPS 1.1.23 sources contain any 'cache.*dir' nor does the SLE10 cups.spec file contain 'cache' so /var/cache/cups (or /etc/cups/yes) do not matter. cupsd does not create any of the other directories and things fail if those directories are missing like # lpadmin -p testy -v file:///dev/null \ -P /usr/share/cups/model/Postscript.ppd.gz -E lpadmin: Unable to create temporary file: No such file or directory and after creating a 'testy' queue # echo hello | lp -d testy lp: unable to create temporary file "/var/spool/cups/tmp/60757b13d6839" - No such file or directory Furthermore in SLE10 cupsd runs as user 'lp' # ps auxw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND lp 9507 0.0 0.4 24508 4652 ? Ss 12:49 0:00 /usr/sbin/cupsd according to /etc/cups/cupsd.conf User lp Group lp RunAsUser Yes So owner group lp:lp of those directories look right on SLE10. Cf. https://en.opensuse.org/SDB:CUPS_in_a_Nutshell that reads (excerpts): ---------------------------------------------------------------- Configuration of the print queues on a CUPS <= 1.5 server ... Up to SUSE LINUX 10.1 we provided CUPS 1.1 and since openSUSE 10.2 we provide CUPS 1.2 which is not fully backward compatible with CUPS 1.1. Therefore in case of an update it is recommended not to use an outdated cupsd.conf from a CUPS 1.1 installation before but to start from scratch with the original cupsd.conf from our CUPS 1.2 (or later) RPM. For example RunAsUser is no longer supported so that since openSUSE 10.2 / CUPS 1.2 the cupsd runs as root and therefore we are back to its default "basic authentication" via system users and system passwords (in /etc/shadow) so that it works again to authenticate as "root" and use the usual root system password. ---------------------------------------------------------------- I will not change how cupsd runs on SLE10 and accordingly I will not introduce changes of those directories for SLE10.
SLE10 is EOL
So RedHat security pointed out the following constraint which changes the assessment of the issue (excerpt from mail exchange): > > cupsdCheckLogFile() calls cupsFileOpen(), which calls cups_open(). > > [these functions are defined in file.c and log.c] > > > > cups_open() verify that the file is not a symlink, via lstat (see the > > code below), and sets `errno` to EPERM : indeed I did not catch that. This changes the assessment of the issue. The check is only made after the fact, however. So while no content will be written to the target file it will still be created for root:root with mode 0644. So this could influence other components in the system that are looking for state files like /etc/setuid-debug. Or it could be used to pre-create configuration files that normally should be readable only by root. Another issue could be a denial-of-service attack against cupsd itself by pointing the symlink to some device file that blocks during open(). Furthermore kernel logic could be triggered that normally cannot be triggered by non-root users, by opening arbitrary device files, proc files or sysfs files etc.
Therefore my RPM changelog text is intentionally somewhat vague about what the actual security issue is ("could lead to"): ------------------------------------------------------------------- - When cupsd creates directories with specific owner group and permissions (usually owner is 'root' and group matches "configure --with-cups-group=lp") specify same owner group and permissions in the RPM spec file to ensure those directories are installed by RPM with the right settings because if those directories were installed by RPM with different settings then cupsd would use them as is and not adjust its specific owner group and permissions which could lead to privilege escalation from 'lp' user to 'root' via symlink attacks e.g. if owner is falsely 'lp' instead of 'root' CVE-2021-25317 (bsc#1184161) ------------------------------------------------------------------- My personal main intent behind the fix is to clean up or old mess in our cups.spec file how we let rpm create those directories versus how cupsd itself creates those directories. A security issue like privilege escalation of the 'lp' user is of secondary importance for me here because noone must ever let arbitrary (untrusted) users access his cupsd, cf. "It is crucial to limit access to CUPS to trusted users" in https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings
(In reply to Johannes Meixner from comment #29) > A security issue like privilege escalation of the 'lp' user > is of secondary importance for me here because noone must > ever let arbitrary (untrusted) users access his cupsd, cf. > "It is crucial to limit access to CUPS to trusted users" in > https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings Fair enough, but was the concern abuse of cups via it's own network sockets? I had imagined someone obtaining shell access because of an entirely unrelated vulnerability (e.g. in a web server). This person could then run print jobs locally and possibly exploit the privilege escalation.
SUSE-SU-2021:1453-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1184161 CVE References: CVE-2021-25317 JIRA References: Sources used: SUSE OpenStack Cloud Crowbar 9 (src): cups-1.7.5-20.36.1 SUSE OpenStack Cloud Crowbar 8 (src): cups-1.7.5-20.36.1 SUSE OpenStack Cloud 9 (src): cups-1.7.5-20.36.1 SUSE OpenStack Cloud 8 (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Software Development Kit 12-SP5 (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server for SAP 12-SP4 (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server for SAP 12-SP3 (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server 12-SP5 (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server 12-SP4-LTSS (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server 12-SP3-LTSS (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server 12-SP3-BCL (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server 12-SP2-LTSS-SAP (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server 12-SP2-LTSS-ERICSSON (src): cups-1.7.5-20.36.1 SUSE Linux Enterprise Server 12-SP2-BCL (src): cups-1.7.5-20.36.1 HPE Helion Openstack 8 (src): cups-1.7.5-20.36.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2021:14712-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1184161 CVE References: CVE-2021-25317 JIRA References: Sources used: SUSE Linux Enterprise Server 11-SP4-LTSS (src): cups-1.3.9-8.46.56.18.1 SUSE Linux Enterprise Point of Sale 11-SP3 (src): cups-1.3.9-8.46.56.18.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): cups-1.3.9-8.46.56.18.1 SUSE Linux Enterprise Debuginfo 11-SP3 (src): cups-1.3.9-8.46.56.18.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2021:1454-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1184161 CVE References: CVE-2021-25317 JIRA References: Sources used: SUSE Manager Server 4.0 (src): cups-2.2.7-3.26.1 SUSE Manager Retail Branch Server 4.0 (src): cups-2.2.7-3.26.1 SUSE Manager Proxy 4.0 (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Server for SAP 15-SP1 (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Server for SAP 15 (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Server 15-SP1-LTSS (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Server 15-SP1-BCL (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Server 15-LTSS (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Module for Development Tools 15-SP3 (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Module for Development Tools 15-SP2 (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Module for Basesystem 15-SP3 (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise Module for Basesystem 15-SP2 (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise High Performance Computing 15-LTSS (src): cups-2.2.7-3.26.1 SUSE Linux Enterprise High Performance Computing 15-ESPOS (src): cups-2.2.7-3.26.1 SUSE Enterprise Storage 6 (src): cups-2.2.7-3.26.1 SUSE CaaS Platform 4.0 (src): cups-2.2.7-3.26.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
openSUSE-SU-2021:0638-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1184161 CVE References: CVE-2021-25317 JIRA References: Sources used: openSUSE Leap 15.2 (src): cups-2.2.7-lp152.9.9.1
Fixed for openSUSE Factory / Tumbleweed: ----------------------------------------------------------------- # osc submitrequest -m 'Fixed CVE-2021-25317 (bsc#1184161)' \ home:jsmeix:branches:Printing cups Printing cups created request id 889938 # osc request accept -m 'Fixed CVE-2021-25317 (bsc#1184161)' \ 889938 Result of change request state: ok openSUSE:Factory Forward this submit to it? ([y]/n)y Fixed CVE-2021-25317 (bsc#1184161) (forwarded request 889938 from jsmeix) New request # 889939 -----------------------------------------------------------------
This is an autogenerated message for OBS integration: This bug (1184161) was mentioned in https://build.opensuse.org/request/show/889939 Factory / cups
Matthias Gerstner I have a question that could be related to this issue here: I got a OBS submitrequest for the package cups in Printing where the '%defattr(-,root,root)' settings in cups.spec should be removed because they "are obsolete at least since SLE12" cf. https://build.opensuse.org/request/show/886970 I failed to find documentation about "defattr is obsolete" (I guess '%defattr(-,root,root)' is used by default) but my main point is if it isn't better for security to explicitly specify '%defattr(-,root,root)' compared to rely on whatever default?
All done, closing.