http://defect.opensolaris.org/bz/show_bug.cgi?id=13166
Michael Hunter <michael.hunter at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michael.hunter at sun.com
--- Comment #4 from Michael Hunter <michael.hunter at sun.com> 2009-12-09
20:21:42 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > So we need to lookup a console login user as we did before to get the
> > > value for
> > > HOME and also set DISPLAY explicitly in the environment I think.
> >
> > I was wondering if the caller's environment information or some useful bit
> > of
> > information might be available from the door; that would give us a more
> > obvious
> > choice in the case where the enm was manually enabled/disabled.
> >
> > That wouldn't work in the case of conditionally activated enms, of course.
> > But
> > I'm nervous about adding the user lookup stuff back in--that has been pretty
> > fragile in phase 0/0.5. The format of the data and the identification of
> > the
> > console user seems to vary depending on how you login, so we had problems
> > working with gdm, for example. And I suspect virtual consoles change
> > things,
> > too. We definitely need to tread carefully here.
> >
> > 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.
>
> 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.
--
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.
