Bug 984960 - Automatic package installation
Automatic package installation
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: realmd (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: beta
: ---
Assigned To: Stef Walter
Patrik Kis
:
Depends On:
Blocks: 917637
  Show dependency treegraph
 
Reported: 2013-07-16 09:27 EDT by Patrik Kis
Modified: 2014-06-13 06:24 EDT (History)
5 users (show)

See Also:
Fixed In Version: realmd-0.14.3-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 06:24:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Notify in terminal output when installing packages (3.91 KB, patch)
2013-07-22 08:05 EDT, Stef Walter
no flags Details | Diff

  None (edit)
Description Patrik Kis 2013-07-16 09:27:18 EDT
Description of problem:

This bug is filed to continue the discussion about realmd automatic package installation, make a decision and of course track the changes if agreed on a solution.

So far the following was said:

pkis:

1/ Automatic package installation
Original bug:
https://bugzilla.redhat.com/show_bug.cgi?id=953852

Description:
realmd installs automatically packages without user intervention or even
warning. Although, this is probably not a security issue as it uses
PackageKit for installation, it is unusual.
So far the dependent packages were installed via rpm dependencies and
admins would expect that packages are installed by applications
dedicated to this task, like rpm, yum, etc. One might be surprised that
the new packages were installed to the system without being notified.
On the other hand it is true that realmd may require many different
packages and not all of them are required for all installations. For
example it is capable to enroll the machine to Microsoft AD and also
IPA, and booth servers requires different clients to install. It has to
be notified that anaconda is dependent on realmd so it is always
installed even with minimal install.
The question is if this practice is acceptable in RHEL or not. If there
are other programs/daemons that install the required packages as they
need it. If there are no such daemons so far, the question if we want to
enable such a precedence in RHEL.

Possible solutions:
a/ realmd does not install packages automatically (already exists a
configuration option) and install the required packages via rpm
dependencies.
b/ realmd does not install packages automatically when it fails to
enroll the machine it exits with error and with the list of required
packages. Admins are still able to change the default behavior and let
realmd install the packages.
c/ realmd can install the packages but prior to do so admins are warned
and they can decide if continue or not.
d/ realmd can automatically install the required packages without user
intervention. This is the current behavior.

----------------------------------------------------------------------------------
sgallagh:

Having read through the BZ linked above, I find myself mostly in
agreement with Stef's assertions. First of all, running realmd already
requires admin privileges, so we know the user has privilege to
perform these functions. RealmD serves only one purpose: to join or
part from a domain. If it's been invoked, I think it's reasonable to
assume that the user has already accepted the idea that they want the
client software on their computer. If they don't already have it
installed, RealmD is automatically acquiring it on their behalf. This
is a good user experience all around, and I think we should continue
with it.

Rather than a confirmation dialog, it might be useful to have realmd
print a notification that it had to install packages X,Y and Z to
accomplish its task, so at least the admin knows that the required
package set on their system has changed.

As far as a precedent, I think we probably want to take each case as
we go. We've already agreed in Fedora that PackageKit should allow
users who are members of the 'wheel' (administrator) group to be able
to install signed packages from the repos without re-entering their
credentials (other users must be challenged for the creds of an
admin). I think that was a reasonable compromise for usability vs.
security. In this particular case, only a superuser can run realmd at
all, so we've already met the authorization requirements.

----------------------------------------------------------------------------------
fweimer:

I'm a bit concerned that automated configuration changes (which includes package installation, but also changes to the general system configuration) interferes poorly with most forms of  centralized system management.  If there is no expectation that realmd works in such scenarios (and that's clearly documented), this is obviously not a concern.

I'm also surprised by the different set of clients that are required.  (I thought that windbind was on the way out, for instance.)  One way to deal with the package installation issue would be to offer subpackages which have the right dependencies at the RPM level and are suitably named.

I agree with the analysis that security-wise, the implicit package installation should not pose any additional problems.  (Always assuming that the packages come from already configured repositories and are not downloaded from somewhere else entirely. 8-)

-- 
Florian Weimer / Red Hat Product Security Team

----------------------------------------------------------------------------------
stefw:

On 21.06.2013 11:49, Florian Weimer wrote:
>> Should have copy os-devel in the original post, sorry for this
>> late-hour mistake. Comments from a wider audience are welcomed!
> 
> I'm a bit concerned that automated configuration changes (which
> includes package installation, but also changes to the general system
> configuration) interferes poorly with most forms of  centralized
> system management.  If there is no expectation that realmd works in
> such scenarios (and that's clearly documented), this is obviously not
> a concern.

Obviously. If you're using puppet or something like that, then you can
setup low level configuration files and join the domain manually using
tools like adcli. There's a whole slew of Red Hat tools you wouldn't use
in those cases, including most of anaconda, authconfig, and maybe not
even yum.

There are always ways to tell realmd not to do installation of packages,
or enabling of services (only configuration). If one is doing puppet,
these options can be used.

However another form of central management *is* a domain. It centrally
manages authentication, identity and to some extent machine/user policy.
realmd is about configuring this central management.

That said there are many other forms of central management beyond
diddling with config files.

 * realmd has a CIM provider for some remote management scenarios.
 * Another form of central management

If there are specific scenarios where realmd interferes with central
management, then raising those issues would obviously be welcome.

> I'm also surprised by the different set of clients that are required.
> (I thought that windbind was on the way out, for instance.)  One way
> to deal with the package installation issue would be to offer
> subpackages which have the right dependencies at the RPM level and
> are suitably named.

I can see why it would be surprising. But joining a realm/domain is not
standard kerberos, and requires specialized packages per provider. It is
different for different types of domain. And then IPA requires even more
client packages than joining an AD domain does.

realmd also supports winbind for certain use cases. Although it is a
non-default option.

FWIW, here are the sets of packages (plus all their dependencies):

http://cgit.freedesktop.org/realmd/realmd/tree/service/realmd-redhat.conf

BTW, once yum is a bit more responsive (ie: dnf), I'll probably move
these into meta packages and track them that way.

> I agree with the analysis that security-wise, the implicit package
> installation should not pose any additional problems.  (Always
> assuming that the packages come from already configured repositories
> and are not downloaded from somewhere else entirely. 8-)

Right, they come from the configured repositories. But I agree with
Stephen that we should be more diligent about logging which packages
have been installed/configured.

Stef

----------------------------------------------------------------------------------
Comment 1 Patrik Kis 2013-07-16 10:12:14 EDT
It seems that the only conclusion so far is that realmd should notify admins about package installation. I personally happy with this solution, what do you think Stef, is it feasible?
Comment 2 Stef Walter 2013-07-22 06:21:12 EDT
(In reply to Patrik Kis from comment #1)
> It seems that the only conclusion so far is that realmd should notify admins
> about package installation. I personally happy with this solution, what do
> you think Stef, is it feasible?

We can do the following:

 * When realmd is being driven from the console, print out a message.
 * Also log clearly to the journal what is going on.

What we cannot do is change every UI that calls realmd to add such notifications. In some cases it's not an admin doing the install, and in some cases realmd is being driven remotely (eg: from scripts, management tools etc.).
Comment 3 Stef Walter 2013-07-22 08:05:12 EDT
Created attachment 776882 [details]
Notify in terminal output when installing packages

Various people have been worried by installing packages
quietly, so notify about what's going on.

In reality *configuring* and *starting* a daemon is far
more worrisome than the installation. It's realmd's job
to configure, enable and start stuff. So if you're properly
worried, remove realmd and do stuff manually.
Comment 4 Stef Walter 2013-07-22 08:07:23 EDT
Attachment 776882 [details] pushed as a209925 - Notify in terminal output when installing packages

Will be part of next realmd point release.
Comment 7 Ludek Smid 2014-06-13 06:24:47 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.