3 Replies Latest reply on Nov 14, 2012 5:19 PM by NorbertB

    Curious desktop behavior after upgrading from Solaris 11 to 11.1

      After upgrading to Solaris 11.1 Gnome starts all applications (not started from a terminal) with launching a
      `"Run program" "As user or role"' window, which needs confirmation. Default is "root".
      Effect: The complete desktop does not start, since also e.g. metacity needs confirmation; but confirmation is impossible, because (just due to missing metacity) about 35 of these confirmation windows are launched on top of each other in the left upper corner during the starting sequence, so that the focus changes permanently.
      The above applies to users with roles=root. "Normal" users get an extremely limited desktop, where e.g. the panels are missing.
      I upgraded as proposed:
      pkg update accept; reboot; pkg update pkg:/package/pkg; pkg update accept; reboot.
      The desktop went fine up to the first upgrade stage.
      pkg install solaris-desktop did not help. (What was missing in s11, that this package was marked "uninstalled"?)
      RBAC: I am maintaining two additional profiles; i.e. modified exec_attr and prof_attr in /etc/security:
      A "Primary Administrator" (unused) and a "Powering Off" (operates as planned).

      Normally these `"Run program" "As user or role"' windows only appear when applications needing privileges shall be started. So, how can I get back this normal state?
        • 1. Re: Curious desktop behavior after upgrading from Solaris 11 to 11.1
          The reason was the "Primary Administrator" profile, copied from Solaris 11 Express, and realized in
          /etc/security/prof_attr as follows:
          "Primary Administrator:RO::Can perform all administrative tasks:auths=solaris.*,solaris.grant;help=RtPriAdmin.html" and in /etc/security/exec_attr as follows:
          "Primary Administrator:solaris:cmd:RO::*:euid=0;egid=0",
          which seems obviously correct, was never a problem in Solaris 11 Express and Solaris 11, and worked.

          Since some S11 Expr. build, the "Primary Administrator" profile was kept on my host as a relict, BUT WAS NOT ASSIGNED TO ANY USER, ROLE, OR OTHER PROFILE, i.e. IT WAS COMPLETELY UNUSED!!
          (The reason is, that it grants far too many rights (imagine a browser session).)

          The entry in /etc/security/prof_attr does no harm.
          The entry in /etc/security/exec_attr causes the described problem, THOUGH NOT USED ANYWISE.
          Solution: Discard the "Primary Administrator" entry in /etc/security/exec_attr (or better: both entries).

          Bug or feature?
          • 2. Re: Curious desktop behavior after upgrading from Solaris 11 to 11.1
            Shawn Walker-Oracle
            The Primary Administrator profile is no longer delivered. It's unsurprising that it wasn't fully automatically removed, since as you said, it was manually copied over.

            From any files where it was previously delivered by the packaging system, it should have been automatically removed (and is from the multiple systems I've checked).
            • 3. Re: Curious desktop behavior after upgrading from Solaris 11 to 11.1
              Hello swalker.

              The Primary Administrator profile (and its descendants) is not longer contained in the RBAC files since these got a better formatting, an adapted manual, a new directory structure with links to local files, and a new way this structure is scanned.
              This was starting with Solaris 11. Since then, RBAC is easy to understand and easily maintainable.
              Thanks to Oracle!
              Any defined profile (and descendants) should not lead to any effect if it is syntactically and semantically correct, as long as it is completely unused, as it was in my case. Or do I think wrong?

              I think, there is a problem in the binaries, handling the security problems coming up with this profile.
              - just the name "Primary Administrator" causes the effect?
              - solaris:cmd:RO::*:euid=0;egid=0 is not longer allowed?
              I did not perform further investigation.