Hello, becomes now probably too much off-topic because now it is mainly about printer drivers and CUPS. On Nov 6 01:02 Christian Boltz wrote (excerpt):
Normal printer driver software packages do not need to run RPM scriptlets.
That sounds like rpm -Uhv --noscripts printer-driver.rpm
Of course - except running /sbin/ldconfig if needed.
The only exception is perhaps running /sbin/ldconfig in %post and %postun.
And fontconfig and update-desktop-files and ... ;-)
Here I was talking about printer driver software packages not about arbitrary third party RPMs.
Having a basic rpm profile ("allow everything outside of /home") might be an option, but even that could break something if someone invents a a new creative way to use %post.
But when the intent is to "forbid changing anything in /home/" then it must break installing RPMs that would change something in /home/ - or what do I misunderstand here?
Speaking about printer drivers - do you think having a profile for cups would be possible?
I do not yet understand what you mean with "a profile for cups" i.e. what your intent behind such a profile should be.
I'm thinking about an AppArmor profile that allows cups to do only what it is supposed to do (take print data from an application, convert it to a format the printer understands, and send it to the printer).
As far as I know the cupsd implements already some limitations what filters and backends can do. Furthermore normally installed filters and backends run as user "lp" which means they are already sufficiently restricted by traditional Unix file permission settings. Regarding the cupsd itself: It runs intentionally as root because - only root can switch user to lp so that this way the filters and backends cannot compromise the cupsd itself (e.g. its config files). - the cupsd does more than what you described. In general we have this discussion every now and then again and again and again and again and again and again... And the result is always the same: The current defaults are the currently best possible balance between reasonable default security and reasonable user-friendly default behaviour. Any attempt to make CUPS more secure by default causes complaints that then this or that functionality doe no longer work out of the box and any attempt to make CUPS more user-friendly by default makes it unacceptable less secure by default.
With such a profile, ideally even malicious printer drivers could "only" access the to-be-printed data, but not everything else.
First and foremost you would need to describe how a program that runs as "lp" could do "everything else" or what exactly you mean with "everything else".
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/view/head...
I wonder why they need an Apparmor profile for CUPS. With "why" I mean their reasoning behind. I wonder what might be wrong in CUPS itself that is not discussed on the CUPS upstream development list and cannot be fixed in CUPS itself so that the only way out for them is to use an AppArmor profile? I think I will ask Martin Pitt and Till Kamppeter about their reasoning behind. In general regarding SUSE's printing system see "User expectations" at https://en.opensuse.org/Concepts_printing
A funny detail is that some %post script creates /dev/lp* - any idea why that might be needed? For bonus points, tell me which package does that, and why /dev/lp* are needed on a laptop that doesn't have a parallel port ;-)
See https://bugzilla.opensuse.org/show_bug.cgi?id=673845 for the full story.
That's a quite long story ;-) (short version: without /dev/lp*, parallel port printers can't be auto-detected)
Not "device auto-detection" but "kernel module auto-loading". Without /dev/lp* parallel port printers cannot work because without /dev/lp* the lp kernel module gets not loaded. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org