Greetings. I am a new Linux user, and I would like to request a patch addition to add functionality for a game.
The information can be found at http://wiki.minegoboom.com/index.php/Running_Continuum_under_Wine
I think for the people that want to learn Linux, applying the patch is a great exercise, like I found. Unfortunately, it is long and involved and might scare off those that have less confidence or don't have a guru handy, but still want to try.
I originally sent this to the wine-patches list and the owner recommended that I send it here.
Thanks
Jason
Hi,
On Sun, Apr 09, 2006 at 01:19:45PM -0400, n1iic Jason Greene wrote:
Greetings. I am a new Linux user, and I would like to request a patch addition to add functionality for a game.
Oh, not so scared, please ;)
The information can be found at http://wiki.minegoboom.com/index.php/Running_Continuum_under_Wine
I think for the people that want to learn Linux, applying the patch is a great exercise, like I found. Unfortunately, it is long and involved and might scare off those that have less confidence or don't have a guru handy, but still want to try.
Problem is that according to the text at the page bottom of the URL mentioned above, this hac^H^H^Hpatch is necessary since Wine doesn't support process capability restriction properly yet. And it's a crude hack since such a check would prevent *all* other programs that happen to pass in a PROCESS_VM_WRITE flag from working properly. IOW, it's a Continuum-specific patch that would fix Continuum and break about 5 dozens other programs horribly. ;)
Since it's thus an obvious ugly hack the only way for this to go in would be by properly implementing process capability restrictions instead. Possibly at this stage of Wine development Wine already supports this feature but it's broken in this specific case.
This stuff should be implemented by following the OpenProcess -> NtOpenProcess -> wineserver open process function link:
find . -name "*.c"|xargs grep "<OpenProcess>" --> ./dlls/kernel/process.c find . -name "*.c"|xargs grep "<NtOpenProcess>" --> ./dlls/ntdll/process.c cd server find . -name "*.c"|xargs grep "<open_process>" --> process.c --> alloc_handle() find . -name "*.c"|xargs grep "<alloc_handle>" --> handle.c alloc_handle()
and verifying whether wineserver does *anything* to check restricted process permissions and then to implement such restrictions in the wineserver if it doesn't exist yet (probably alloc_handle() needs to be changed or so).
Andreas Mohr
Andreas Mohr wrote:
Hi,
On Sun, Apr 09, 2006 at 01:19:45PM -0400, n1iic Jason Greene wrote:
Greetings. I am a new Linux user, and I would like to request a patch addition to add functionality for a game.
Oh, not so scared, please ;)
The information can be found at http://wiki.minegoboom.com/index.php/Running_Continuum_under_Wine
I think for the people that want to learn Linux, applying the patch is a great exercise, like I found. Unfortunately, it is long and involved and might scare off those that have less confidence or don't have a guru handy, but still want to try.
Problem is that according to the text at the page bottom of the URL mentioned above, this hac^H^H^Hpatch is necessary since Wine doesn't support process capability restriction properly yet. And it's a crude hack since such a check would prevent *all* other programs that happen to pass in a PROCESS_VM_WRITE flag from working properly. IOW, it's a Continuum-specific patch that would fix Continuum and break about 5 dozens other programs horribly. ;)
Since it's thus an obvious ugly hack the only way for this to go in would be by properly implementing process capability restrictions instead. Possibly at this stage of Wine development Wine already supports this feature but it's broken in this specific case.
This stuff should be implemented by following the OpenProcess -> NtOpenProcess -> wineserver open process function link:
find . -name "*.c"|xargs grep "<OpenProcess>" --> ./dlls/kernel/process.c find . -name "*.c"|xargs grep "<NtOpenProcess>" --> ./dlls/ntdll/process.c cd server find . -name "*.c"|xargs grep "<open_process>" --> process.c --> alloc_handle() find . -name "*.c"|xargs grep "<alloc_handle>" --> handle.c alloc_handle()
and verifying whether wineserver does *anything* to check restricted process permissions and then to implement such restrictions in the wineserver if it doesn't exist yet (probably alloc_handle() needs to be changed or so).
Without having any debug logs to go on, I would guess that the app is using NT ACLs on the process to remove the PROCESS_VM_WRITE access right. The framework is there in the wineserver to do access checks, but it isn't implemented for any objects yet.