http://defect.opensolaris.org/bz/show_bug.cgi?id=13166
--- Comment #6 from Michael Hunter <michael.hunter at sun.com> 2009-12-09 21:14:07 UTC --- (In reply to comment #5) > (In reply to comment #4) > > > > > The GUI is running under the console user's environment, right? Any > > > > chance we > > > > could exploit that? > > > > door_cred() will tell us the uid/gid/euid/egid/pid of the client. The GUI > > is > > running as the users UID. From there you can get the relevant environment. > > > > In discussing this with Darren, he suggested something similar. It may make > sense to define a specific GUI environment registration function in libnwam, > i.e. > > nwam_error_t nwam_gui_init(); > > ...which would be called by the GUI and which we would use in nwamd to > establish the relevant environment variables for ENM execution (we can't use > nwam_events_init() since this can also be called by nwamadm). In the cases where nwamadm is running with the appropriate environment then it should set it up. When there isn't the appropriate environment then there is nothing we can do anyways to make zenity or whatever run. I don't see why we should treat clients differently. > > > > > > > I wonder if we need to take a step back here and figure out what the > > > execution > > > environment of the ENM scripts should be. At present, they run as > > > user/group > > > netadm/netadm. Is there a way that we can ensure this user has access to > > > the > > > display rather than grabbing settings from other user's environments, > > > e.g. by > > > setting up an .Xauthority file in netadm's HOME directory? I tried > > > experimenting with xauth but without success. Maybe Darren might have some > > > suggestions here... > > > > We definitely need to more tightly specify what an ENM can expect in their > > environment. > > > > mph at tahoe:~$ pargs -e `pgrep nwam-manager` | grep Xau > > envp[32]: XAUTHORITY=/export/home/mph/.Xauthority > > mph at tahoe:~$ > > > > > > I wonder instead of doing the stuff I describe above if it might not be > > better > > if the client just passed the right environment when executing an ENM. That > > way the right thing happens GUIless, GUIfull, etc. > > > > I didn't realize that ENMs ran as netadm. That seems like a security > > issue. > > Also if they run as netadm and we use the users environment there might be > > issue. > > Yeah, it seems a bit hacky to take the pieces from the GUI user environment > and > add them to the netadm user's environment in order to get the display working > for ENMs. On the other side, we can't just run as the GUI user since that > leaves us without options when the GUI is not present (it would be weird if we > ran ENM scripts as netadm when the GUI wasn't present but as the GUI user when > it was). Not sure what the right answer is here... I not saying run as the GUI user. I'm saying run as the control program user (e.g. nwamadm). The sticky point is when we are automatic and nobody has talked to us. The cases I can think of: * enterprise - text only * startup - gnome isn't available yet * triggered invocation of ENM In all of these cases there is no guarantee of interaction. If the user doesn't have a GUI and wants to use an ENM that needs interaction then I think it is okay to leave him on his own. We could have a registry program which the user could invoke which merely tells us what the environment to run ENMs as (or as an option to nwamadm). Then in GUIless environments where the user wants interaction then we could pass him a reasonable environment (one with fds pointed at /dev/console being the major point?). -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
