Re: [SCIENTIFIC-LINUX-USERS] Snap - the better,higher,faster etc

[Tom H]

On Sat, Jun 18, 2016 at 2:33 PM, Nico Kadel-Garcia  wrote:
> On Sat, Jun 18, 2016 at 7:09 AM, Tom H  wrote:


>> The first that I heard of snaps being available on non-Ubuntu systems
>> was on the fedora-devel@ list where the poster floated the idea of
>> banning snapd because it might get a first-to-market advantage over
>> flatpak, a more or less similar Red Hat and Gnome technology.
>
> Which got shot down fast as a bad reason to reject the software.

Thankfully!


>> It's interesting (and depressing) to see otherwise rational people
>> lose the plot like this, just like many did regarding systemd or many
>> are here in the UK regarding Brexit.
>
> Permit me to call "straw man argument fallacy" on this one. It was one
> person on a mailing list, who was shot down very quickly. The many
> reasons to dislike systemd's policies, practices, size, and creeping
> featuritis are well documented and remain a risk. Take a look at the
> threads when it tried to replace "/etc/resolv.conf" with an
> inconsistently managed symlink into systemd's DHCP configurations, and
> its more recent attempts to disconnect all background processes not
> tied to a user session that are not directly managed by systemd.
>
> Shall we break remotely run tmux, screen, ssh-agent, and nohup based
> long-running backgrounded tasks with no warning and no logging? What a
> magnificent idea, let's break stuff without telling anyone

My point about "losing the plot" wasn't just about the moron who
wanted to ban snap/snappy/snapd or whatever the actual package is
called.

There wasn't even one positive thing said, there wasn't any
fact-checking before saying "it sucks because of ...". It was an
unending attack on the technology because it originated at Canonical
and because it might pre-empt the use of RH's Flatpak.

The technology was intended as Ubuntu-only and, if Canonical/Ubuntu
are to be believed, people from other distros asked them about porting
snaps so they did some work towards that. And then there was a
premature press release...

resolv.conf: IIRC, the problem was that if you weren't using
systemd-resolved, you were left with a dangling symlink.

Disconnection of background processes: The current solution's an OTT
solution to what could easily be regarded as buggy Freedesktop and
Gnome software. No one brought up during the fedora-devel@ discussion
the possibility of creating a new systemd.special unit, logout.target,
that would kill all the misbehaving processes like pulseaudio,
evolution-*, ... at logout while allowing nohup & co to work as
intended, as the upstream dbus maintainer suggested when he opened
this can of worms. Whatever their other good and bad qualities, the
systemd developers have a special talent for pissing people off.


>> Ubuntu/Canonical created its own system for installing
>> self-contained apps a-la Android and iOS. AIUI, these apps are
>> confined on Ubuntu using AppArmor.
>>
>> According to Mark Shuttleworth, non-Ubuntu developers asked whether
>> patches would be accepted to port snaps to other distros. So some
>> work's been done and it's resulted in the press release and all this
>> brouhaha.
>
> I'm extremely leery of any system that tries to "bundle all the system
> tools" to run packages. It might be usable for containers, but it
> presents real library and package management problems for deployed
> such working environments. The approach is very familiar: it used to
> be done with chroot a lot, it's more recently been done with docker
> and Vagrant, and I don't see any compelling need for more such tools.

There are people on this list who regularly ask about software that's
more recent than what's in SL's repos. Snaps/Flatpaks would simplify
their lives.

AFAIK, Android and iOS apps "bundle all the system tools." Given how
many of these phones are used in the world, isn't it enough of a proof
of concept for you?

Re: SL7 CUPS/SELinux problem trying to install Brother HL-3150CDN printer driver

[David Sommerseth]

On 29/06/16 17:21, jdow wrote:
> Nonsense.
> 
> Haven't met a distro yet that has SELinux correctly setup from the
> gitgo. It still doesn't completely like samba on my 6.6 install, for
> example. I had to make some "fake" changes to get something else rather
> pedestrian to work. (It's in the archives some time back with projected
> fix pushed all the way out to 6.7.)

Have you filed any bugzillas for these issues?

I'm really curious what you do which causes this.  I've been running
both Samba and NFS without issues - well, yes, I sometimes had to flip a
SELinux boolean or two, or perhaps adding a new file path so files got
labelled correctly as the paths were not standard paths.  But that's
usually a 3 minute fix.  This is even on SL6.x.


--
kind regards,

David Sommerseth




> On 2016-06-29 03:12, David Sommerseth wrote:
>> On 29/06/16 10:00, Bill Maidment wrote:
>>> My final attempt was successful, sort of.
>>> I switched SElinux to enabled and rebooted, then the install worked OK.
>>> Then I had to use a live CD to be able to boot, changed SElinux to
>>> disabled, and reboot again.
>>> Then I had to us lpoptions to set the default parameters as the CUPS
>>> gui tool refused to change anything.
>>> Phew. What a tortuous route.
>>> Back to sleep now.
>>
>> 
>>
>> Let this be an example why NOT to disable SELinux.  SELinux has been (if
>> my memory serves me right) available since Fedora 6 (released in 2006)
>> and RHEL *4*!  I believe it was turned on by default in Fedora 8 and
>> RHEL 5.  And in RHEL 6 you could no longer disable SELinux at install
>> time.
>>
>> SELinux is not the obstacle it once was over a decade ago.  So if you
>> have issues when it is enabled, learn to use the proper tools to debug
>> and fix it correctly.  (audit2why, audit2allow, semanage, restorecon,
>> etc, etc)
>>
>> Disabling SELinux is in 2016 *not* a solution and can barely be
>> considered a workaround.
>>
>> Refusing to to use, accept and learn SELinux will serve you no good in
>> the long run.
>>
>> Seriously, I've been running a various amount of Fedora, RHEL/SL/CentOS
>> installations and versions over the last 8-9 years.  In SL7 SELinux have
>> not bitten me much at all (only one issue with logrotate on servers
>> running Zimbra Collaboration Suite, that's all).   I have the last 6-7
>> years never needed to disable SELinux to accomplish my tasks.  Yes, I've
>> put systems into permissive modes to see if SELinux was to blame, but
>> mostly that was not the issue.
>>
>> So if you are badly hit by SELinux troubles, you need to look into if
>> you or the software you use are doing the right things.
>>
>> 
>>
>>
>> -- 
>> kind regards,
>>
>> David Sommerseth
>>
>>
>>>
>>> -Original message-
 From:Bill Maidment 
 Sent: Wednesday 29th June 2016 16:34
 To: Akemi Yagi ; SL Users
 
 Subject: RE: SL7 CUPS/SELinux problem trying to install Brother
 HL-3150CDN printer driver

 Well I've heard back from Brother and they suggest that my SElinux
 set up has a problem. They recommended that I do
 semodule -vR
 This gave me exactly the same error messages. Then I did semodule
 -vB which worked OK, but repeating semodule -vR still gives

 [root@ferguson src]# semodule -vB
 Committing changes:
 Ok: transaction number 0.
 [root@ferguson src]# semodule -vR
 SELinux:  Could not downgrade policy file
 /etc/selinux/targeted/policy/policy.29, searching for an older version.
 SELinux:  Could not open policy file <=
 /etc/selinux/targeted/policy/policy.29:  No such file or directory
 /sbin/load_policy:  Can't load policy:  No such file or directory
 libsemanage.semanage_reload_policy: load_policy returned error code
 2. (No such file or directory).
 [root@ferguson src]#

 This is happening on two different SL 7.2 machines with SElinux
 installed but disabled.

 I even tried uninstalling selinux* but that got me into deeper trouble.

 [root@ferguson src]# rpm -qv selinux-policy
 selinux-policy-3.13.1-60.el7_2.7.noarch

 Is there an issue with this version of selinux???

 Cheers
 Bill

 -Original message-
> From:Bill Maidment 
> Sent: Saturday 25th June 2016 17:26
> To: Akemi Yagi ; SL Users
> 
> Subject: RE: SL7 CUPS/SELinux problem trying to install Brother
> HL-3150CDN printer driver
>
> Thanks for the suggestion Akemi.
> Unfortunately, it made no difference.
> I'm awaiting comment from Brother, but I suspect they will say
> change to Ubuntu :-(
> Cheers
> Bill
>
> -Original message-
>> From:Akemi Yagi 
>> Sent: Saturday 25th June 2016 1:10
>> To: SL Users 
>> Subject: Re: SL7 CUPS/SELinux 

Re: SL7 CUPS/SELinux problem trying to install Brother HL-3150CDN printer driver

[David Sommerseth]

On 30/06/16 07:23, Nico Kadel-Garcia wrote:
> On Wed, Jun 29, 2016 at 6:12 AM, David Sommerseth
[...snip...]
>> SELinux is not the obstacle it once was over a decade ago.  So if you
>> have issues when it is enabled, learn to use the proper tools to debug
>> and fix it correctly.  (audit2why, audit2allow, semanage, restorecon,
>> etc, etc)
> 
> Until and unless you use something that is not from an RHEL or
> Scientific Linux published RPM that has gone through real QA.

I fail to see that being an SELinux issue.  That's merely an issue with
the ISV ignoring SELinux.  If ISVs just plain ignore SELinux, can you
then trust they take security seriously?  Regardless, in these cases the
monkey should be put on the ISV's shoulder.  This basically is the same
situation as older Windows applications failing to run because it
expected the end user to have admin privileges while there would be no
real reason for such a need.

[...snip...]

>> Seriously, I've been running a various amount of Fedora, RHEL/SL/CentOS
>> installations and versions over the last 8-9 years.  In SL7 SELinux have
>> not bitten me much at all (only one issue with logrotate on servers
>> running Zimbra Collaboration Suite, that's all).   I have the last 6-7
>> years never needed to disable SELinux to accomplish my tasks.  Yes, I've
>> put systems into permissive modes to see if SELinux was to blame, but
>> mostly that was not the issue.
> 
> It's gotten better. As soon as you start hand-compiling servers for
> development reasons, or start writing your own RPM's, it starts
> costing serious engineering time.

If you use standardized file paths for storing/accessing files, these
issues are seldom an issue if you're using the targeted SELinux profile.
 By default software not having an explicit SELinux policy will run as
unconfined_t, which means SELinux normally would not be an obstacle.

There are however some limitations to some files/directories where the
security impact is too high.  IIRC, /etc/shadow is one of those files
which have such an extra security check.

To put together a new SELinux profile might be easy or it might be hard,
it all depends on how complex your package is and how tight you want the
security around it.

>> So if you are badly hit by SELinux troubles, you need to look into if
>> you or the software you use are doing the right things.
>>
>> 
> 
> Permissive is your friend. Disabled can cause its own problems.

Fully agree!  However, running in permissive mode might fill your logs
quicker if you have a lot of denials.


--
kind regards,

David Sommerseth