The symptom you are describing seem to imply that the window system doesn't think this primaryadmin is actually a role. That's odd. But if the client isn't of type=role, then the window manager will prevent it from occupying a role workspace.
See if you can dermine the uid of the Terminal window that's showing up in the wrong workspace. --Glenn Josh Fisher wrote: > Sorry for the confusion. Our main concern is still, why does a labeled > terminal window opened by the primaryadmin role, which has only been given > the primaryadmin right, open in the primary desktop of the user which has > assumed primaryadmin? We don't want this functionality. We want Primayadmin > operations to occur in its own labeled workspace. Also after the labeled > primaryadmin window has opened in the user's primary worksapce we have tried > to move the primaryadmin window back to it's own workspace however, the > primaryadmin workspace is not an option in the Occupy Workspace menu. We have > not given any privileges to any CDE actions. We are using the icons provided > as part of the trusted workspace bar. I may be a little confused with your > description of the file_dac_read priviege but, I would not think assigning a > privilege would be needed in this circumstance. > > We will test out the automounter in the zones for TJDS to see if we can > restore desktop icons/functionality for users/roles in labeled zones > workspace when logged into TJDS. Once that is done we will see if a window > opened by a role still opens in the users workspace in TJDS. > > Thank you very much for your help and sorry again for the confusion. > > > This message posted from opensolaris.org > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org >
