Project

General

Profile

Bug #4100

GNOME panel and menus mostly empty (151a8)

Added by Gordon Ross over 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Desktop (JDS)
Target version:
-
Start date:
2013-09-04
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

After an upgrade from 151a7 to 151a8 (and thanks for the work there, btw:)
all my gnome panel launchers are missing. The "Oi" start button is there but
most of the menu items normally found there are missing too.

I booted my previous BE and everything came back.
Any other data I should gather?

History

#1

Updated by Milan Jurik over 6 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 90
  • Tags deleted (needs-triage)

The root cause is in broken RBAC support. I removed it for the next a9 release.

#2

Updated by Nikola M. over 6 years ago

Milan Jurik wrote:

The root cause is in broken RBAC support. I removed it for the next a9 release.

Could you just explain this a little bit.
What was actually removed from GNOME, and why RBAC support in GNOME is broken and what it used to provide and how and what is removed now?
Is that, like support for function of separate desktops to run applications from different zones and/or separate users/user access levels by same user?
Or support for GNOME for every app on desktop te be run with different privileges level or how it suppose to work
and what/how hard it is to make working?

#3

Updated by Milan Jurik over 6 years ago

Nikola M. wrote:

Milan Jurik wrote:

The root cause is in broken RBAC support. I removed it for the next a9 release.

Could you just explain this a little bit.
What was actually removed from GNOME, and why RBAC support in GNOME is broken and what it used to provide and how and what is removed now?
Is that, like support for function of separate desktops to run applications from different zones and/or separate users/user access levels by same user?
Or support for GNOME for every app on desktop te be run with different privileges level or how it suppose to work
and what/how hard it is to make working?

The set of patches is about functionality not to show something to user on which the user has no rights (some apps, applets etc.). It does not remove any feature from OI JDS because it was not part of OI yet. And after evaluation of the patches I think they have very limited benefit in comparison to amount of work needs to be done.

#4

Updated by Nikola M. over 6 years ago

Isn't RBAC essential in opensolaris, Solaris and illumos/OI and the difference from Linux, that is runing sudo with Root permissions for everything?

RBAC and pfexec as I know allows gradual permission to users.
Is it then GNOME not behaving like RBAC is saying it should, therefore
it is not hiding from non-priviledged users things in GNOME that he does not have permissions to?
Maybe we should have fixed more things that used to work in the past,
and not killing unique features instead, or we will get back to it some day.. probably.

Was there some times before, when also Trusted extensions was removed, too
,like having applications from different Zones running on their own desktop?
https://blogs.oracle.com/darren/entry/solaris_11_has_the_security

Is this why Packagemanager is not working for a long time and I can not set time/date in GNOME anymore?

#5

Updated by Milan Jurik over 6 years ago

"It does not remove any feature from OI JDS because it was not part of OI yet."

Bugtracking system is not for discussions. Feel free to look at those patches, you can find them in JDS gate and fix them. But their benefit is so limited for typical JDS user that I do not see benefit in maintaining them and wasting resources.

I do not know why packagemanager is not working for you. I know about bug in pkg for OI making it not working sometimes and I know about bug in python for hipster making it not working. It is not relevant to this issue.

Btw., I plan to remove Trusted JDS. If nobody will stand up and work on it. I have no testing environment (e.g. no Directory Server) and it is problem to maintain something you cannot test. I asked if somebody is using it. Nobody. So what?

Time/date problem is not impacted by this. Low priority issue for me, bug analysis and patches are welcomed.

#6

Updated by Nikola M. about 6 years ago

As I read RBAC support in GNOME is not only for hiding apps?
But also for not to be asking on root password to set up wireless, to manage printers, to start packagemanager and install programs then it is obvious step back with not implementing RBAC altogether for GNOME user experience. I just loosely understand OI dev process.

#7

Updated by Milan Jurik about 6 years ago

Nikola M. wrote:

As I read RBAC support in GNOME is not only for hiding apps?
But also for not to be asking on root password to set up wireless, to manage printers, to start packagemanager and install programs then it is obvious step back with not implementing RBAC altogether for GNOME user experience. I just loosely understand OI dev process.

You read it wrong.

#8

Updated by Richard PALO about 6 years ago

I believe the RBAC observation is still pertinent.

What I can't seem to locate in the oi-jds tree are the updates to gnome-session as well as the useful multi-user-desktop pieces/parts.

This seems to facilitate managing "/schemas/desktop/gnome/lockdown/allowed_applications"

In particular https://hg.openindiana.org/upstream/oracle/spec-files/file/1ff6784d9b6f/patches/gnome-session-22-gconf-lockdown.diff and company don't seem to be integrated.

perhaps the upstream link could/should also be updated to https://hg.java.net/hg/solaris-desktop~spec-files

#9

Updated by Milan Jurik about 6 years ago

Richard PALO wrote:

I believe the RBAC observation is still pertinent.

What I can't seem to locate in the oi-jds tree are the updates to gnome-session as well as the useful multi-user-desktop pieces/parts.

This seems to facilitate managing "/schemas/desktop/gnome/lockdown/allowed_applications"

In particular https://hg.openindiana.org/upstream/oracle/spec-files/file/1ff6784d9b6f/patches/gnome-session-22-gconf-lockdown.diff and company don't seem to be integrated.

perhaps the upstream link could/should also be updated to https://hg.java.net/hg/solaris-desktop~spec-files

I do not plan to add RBAC evaluation to JDS infrastructure. The benefit is very limited, there is no security benefit I see. Do you have real use case?

#10

Updated by Richard PALO about 6 years ago

Well, yes, multi-user login to a server (headless or otherwise) via extremely thin clients.

Currently, when root (or the roughly equivalent Primary Administrator) all menus/programs are authorised, otherwise it is done on an individual (menu/program) basis (that is a profile check). This is fine.

I think the RBAC work should stay, but perhaps someone with access to sunray desktop on or*cle could take a look at the /etc/security/prof_attr and /etc/security/exec_attr (and/or exec_attr.d/) in order to see how they did it.

I'm doing it a bit manually, but it is hard labour (luckily very very few programs are needed).

#11

Updated by Richard PALO about 6 years ago

Just noticed that the new manpage has some useful information, as well...
solaris-desktop/manpages/man1/gnome-panel.1

in particular

RBAC can be configured to allow users access to a Rights
Profile. If a program can be run with a Rights Profile
associated with the user, then the program is made available
to the user and is run by the GNOME Panel with pfexec(1).
RBAC can be configured to allow users access to a role. If
not using Trusted Extensions and if a program can be run
with a user or role the user can assume, then the program is
made available to the user and is run by the GNOME Panel
with gksu(1). Programs that are not explicitly assigned
security attributes in Rights Profiles are not filtered by
the GNOME panel.
If using Trusted Extensions or if the
user's shell is a pfexec(1) enabled shell like pfsh(1) or
pfbash(1), then the panel runs all programs not explicitly
assigned security attributes in Rights Profiles with
pfexec(1). Running with pfexec(1) ensures that the user's
profile assignments apply to all child processes, as well.
Users can also be disallowed from running programs by confi-
guring RBAC. For example, by using the "Stop" profile.

When processing GNOME Panel menu and launchers, it determines
the executable by checking the associated application
or launcher desktop file. The GNOME Panel checks the
executables associated with the Exec and TryExec keys of the
desktop file to see if they are associated with a profile.
If both are associated with a profile, the GNOME Panel uses
the profile associated with the Exec key. When processing
GNOME Panel applets, it determines the executable by checking
the applet factory's bonobo server file and uses the
value specified in the "location" element of the factory's
bonobo server configuration file to see if it is associated
with a profile.

I guess in summary, there do seem to be some missing parts as
it should not be necessary to add any particular rights/profiles
for simple non-privileged programs.

#12

Updated by Udo Grabowski about 6 years ago

All problems gone in a9, fixed.

#13

Updated by Milan Jurik about 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF