[wingide-users] Remote agent permissions for v6.1

[Tom Stambaugh via wingide-users]

I've encountered and ultimately resolved an apparent permissions issue
for /usr/lib/wingide6 with the v6.1 update. Details follow.

I've just updated from v6.0 to v6.1. I run WingIDE on my local Windows 7
host, and I'm debugging code that lives in a CentOS 7 guest VM (on the
same machine) running on VMWare. Remote debugging (using the remote
agent etc) has been working fine until this update.

When I launched v6.1, it connected to the guest just like it always has.
It then complained that "The remote agent's version (6.0.12) does not
match Wing's version (6.1.0). Updating the remote agent is recommended".
That dialog includes a check-box that says ("Don't show this dialog
again") as well as an "Update Remote Agent" button and a "Not Now" button.

I clicked the "Update Remote Agent" button (leaving the check-box
empty). Things churned, a succession of (seven?) steps flowed by, and
then the same dialog popped up -- this time without the "Don't show this
dialog again" option. Once this happened, I was in an infinite loop. The
first time I ran this, it complained that it couldn't find wingdebugpw
in /usr/lib/wingide6. I found and copied it from my ~/.wingide6
directory (on the guest).

I was able to resolve this issue by changing the permissions of
/usr/lib/wingide6 from a shell connected as root to the guest VM: "chmod
-R 777 /usr/lib/wingide6".

This works, and it's ok for me because I'm the only one using this local
VM on my PC.

I note that after changing the permissions of /usr/lib/wingide6 and
running "Update Remote Agent", I see new touch dates for the following:
- wingdebugpw
- wingdbstub.py
- wingdb
- VERSION
- remoteagent.py
- LICENSE.txt

This all may be operator error on my part. There are enough moving parts
in all this that I'm not sure how best to configure all this. I
generally get something working and then avoid touching it as a result.

Thanks,
Tom S.

[Wingware Support via wingide-users]

Post by Tom Stambaugh via wingide-users
I've encountered and ultimately resolved an apparent permissions issue
for /usr/lib/wingide6 with the v6.1 update. Details follow.

It sounds like the bug is that Wing fails to correctly handle the case
where it cannot write to the selected WINGHOME for the remote agent
configuration. Is that correct?

From a security standpoint at least, anything in /usr/lib shouldn't
really be chmod 777... better to set WINGHOME in the remote agent
configuration to some other location writable by the remote user. We're
working on changing this so the installation of the remote agent is
automatically managed to avoid confusion and problems like this.

Thanks for reporting this problem!
--
Stephan Deibel
Wingware | Python IDE

The Intelligent Development Environment for Python Programmers

wingware.com


_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide

[Tom Stambaugh via wingide-users]

I hear you about the security shortcomings of my workaround. That isn't
a concern for me in this particular instance because it's my own project
being done on a guest VM running on a well-isolated machine in my own
home, but it's certainly not recommended for more general use. I also
wondered about doing a "chown -R hex:hex /usr/wingide6" where "hex" is
the user and group that runs wing.

Since I don't remember having this issue in v6.0, perhaps something
changed in v6.1 to provoke it. The contents of my /usr/lib/wingide6 were
all from prior installations and each owned by "root:root". That tells
me that if the agent attempted these same changes in the v6.0 release,
it did so as root.

Regarding the value of WINGHOME itself, I looked in all the directories
that contain a "wingdebugpw". None of those have contents similar to
/usr/lib/wingide6.

Thanks,
Tom S.

Post by Wingware Support via wingide-users

Post by Tom Stambaugh via wingide-users
I've encountered and ultimately resolved an apparent permissions issue
for /usr/lib/wingide6 with the v6.1 update. Details follow.

It sounds like the bug is that Wing fails to correctly handle the case
where it cannot write to the selected WINGHOME for the remote agent
configuration.  Is that correct?
From a security standpoint at least, anything in /usr/lib shouldn't
really be chmod 777... better to set WINGHOME in the remote agent
configuration to some other location writable by the remote user.  We're
working on changing this so the installation of the remote agent is
automatically managed to avoid confusion and problems like this.
Thanks for reporting this problem!

[Wingware Support via wingide-users]

Post by Tom Stambaugh via wingide-users
I hear you about the security shortcomings of my workaround. That isn't
a concern for me in this particular instance because it's my own project
being done on a guest VM running on a well-isolated machine in my own
home, but it's certainly not recommended for more general use. I also
wondered about doing a "chown -R hex:hex /usr/wingide6" where "hex" is
the user and group that runs wing.
Since I don't remember having this issue in v6.0, perhaps something
changed in v6.1 to provoke it. The contents of my /usr/lib/wingide6 were
all from prior installations and each owned by "root:root". That tells
me that if the agent attempted these same changes in the v6.0 release,
it did so as root.

Both Wing 6.0 and 6.1 install the remote agent the same way and use the
remote user name specified in the remote host configuration (and
possible in ssh configuration). It would either have write access to
the selected WINGHOME or not, since this is determined by the remote host.

Post by Tom Stambaugh via wingide-users
Regarding the value of WINGHOME itself, I looked in all the directories
that contain a "wingdebugpw". None of those have contents similar to
/usr/lib/wingide6.

I suspect you have Wing installed on the remote machine so
/usr/lib/wingide6 has the complete IDE install while any other value of
WINGHOME in the remote host configuration would install just the remote
agent, which is a small subset.

One theory here is that Wing 6.0 worked with /usr/bin/wingide6 because
it was also Wing 6.0 but Wing 6.1 does not and thus tried to install the
remote agent.

We recommend against using a Wing installation as WINGHOME for the
remote host configuration. This is confusing which is why we going to
change remote host installation to be managed automatically in the future.
--
Stephan Deibel
Wingware | Python IDE

The Intelligent Development Environment for Python Programmers

wingware.com

_________________________________________________
Wing IDE users list
http://wingware.com/lists/wingide