[refpolicy] [PATCH v2 1/5] wm: update the window manager (wm) module and enable its role template (v5)

[guido@trentalancia.net (Guido Trentalancia)]

On Wed, 14/12/2016 at 21.01 +0800, Jason Zaman wrote:
> 
> 
> On 14 Dec 2016 09:54, "Guido Trentalancia via refpolicy" <refpolicy@o
> ss.tresys.com> wrote:
> Enable the window manager role (wm contrib module) and update
> the module to work with gnome-shell.
> 
> This patch requires the following recently posted patch for the
> games module:
> 
> [PATCH v3 1/2] games: general update and improved pulseaudio
> integration
> http://oss.tresys.com/pipermail/refpolicy/2016-December/008679.html
> 
> This patch has received some testing with the following two
> configurations:
> - gnome-shell executing in normal mode (with display managers
> other than gdm, such as xdm from XOrg);
> - gnome-shell executing in gdm mode (with the Gnome Display
> Manager).
> 
> Patches 3/5, 4/5 and 5/5 are needed when gnome-shell is used
> in conjunction with gdm.
> 
> Since the window managers are not limited by gnome-shell, this latter
> version of the patch (along with part 2/5) uses separate optional
> conditionals for the gnome and wm role templates.
> 
> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> ---
> ?policy/modules/contrib/colord.te? ?|? ? 5 ++
> ?policy/modules/contrib/dbus.te? ? ?|? ? 5 ++
> ?policy/modules/contrib/wm.if? ? ? ?|? ?43 +++++++++++++++++-
> ?policy/modules/contrib/wm.te? ? ? ?|? ?88
> ++++++++++++++++++++++++++++++++++++-
> ?policy/modules/roles/staff.te? ? ? |? ? 8 ++-
> ?policy/modules/roles/sysadm.te? ? ?|? ? 4 +
> ?policy/modules/roles/unprivuser.te |? ? 8 ++-
> ?7 files changed, 155 insertions(+), 6 deletions(-)

[...]

> @@ -55,10 +96,51 @@ optional_policy(`
> ?')
> 
> ?optional_policy(`
> +? ? ? ?consolekit_dbus_chat(wm_domain)
> +')
> +
> +optional_policy(`
> ? ? ? ? devicekit_dbus_chat_power(wm_domain)
> ?')
> 
> ?optional_policy(`
> +? ? ? ?evolution_domtrans(wm_domain)
> +
> +? ? ? ?optional_policy(`
> +? ? ? ? ? ? ? ?evolution_dbus_chat(wm_domain)
> +? ? ? ? ? ? ? ?evolution_alarm_dbus_chat(wm_domain)
> +? ? ? ?')
> +')
> +
> +optional_policy(`
> +? ? ? ?games_domtrans(wm_domain)
> +
> +? ? ? ?optional_policy(`
> +? ? ? ? ? ? ? ?games_dbus_chat(wm_domain)
> +? ? ? ?')
> +')
> +
> +optional_policy(`
> +? ? ? ?java_domtrans(wm_domain)
> +')
> +
> +optional_policy(`
> +? ? ? ?mono_domtrans(wm_domain)
> +')
> +
> +optional_policy(`
> +? ? ? ?mozilla_domtrans(wm_domain)
> +
> +? ? ? ?optional_policy(`
> +? ? ? ? ? ? ? ?mozilla_dbus_chat(wm_domain)
> +? ? ? ?')
> +')
> +
> +optional_policy(`
> +? ? ? ?mplayer_domtrans(wm_domain)
> +')
> +
> +optional_policy(`
> ? ? ? ? networkmanager_dbus_chat(wm_domain)
> ?')
> 
> Whoa are we going to have to add every single application to
> wm_domain to be able to run it? That will get annoying super fast.
> Isn't there an application_domain attribute we can use? If there
> isn't we might want to reverse this so X application types instead
> declare that wm can run them (something like the application_type
> interface)

I am now trying to get back to you on this, provided that I understood
the meaning of what you proposed...

I suppose you are suggesting to use an interface such as
wm_application() in the module of each application that needs to be run
by the window manager and avoid calling applicationname_domtrans() from
the wm module.

Even if that was possible, there would be a loss of visibility in the
wm module about what applications it can actually run.

The latter is undesirable in my opinion and defeats the purpose of
having a separate wm module to control what the window manager can and
cannot do, because at that point it would be each application module
which decides if the application can run or not in the window manager.

Guido