Access Control Functions
lawson_whitney at juno.com
lawson_whitney at juno.com
Fri Nov 30 23:25:34 CST 2001
On Fri, 30 Nov 2001, Karl Bielefeldt wrote:
> I am new to open source development and to the wine project so please
> forgive me for sounding like a newbie. I think wine is great and the key to
> the growth of Linux in the desktop market.
> I decided to begin my efforts by debugging the installation of MS Money 2001
> (my wife's must-have MS program) on a completely non-windows box. This led
> to needing to install the msiexec installer (instmsia.exe, available from MS
I contribute to wine so we can have windows without microsoft, and what
do people do with it? Try to get it to run microsoft apps, of course.
Don't mind me, I am only the oddest of wine's 300 odd authors.
> Everything works okay until we get to the access control functions.
> advapi32.OpenProcessToken calls ntdll.OpenProcessToken, which is just a
> stub. Now, as far as I can tell, the stubs default to the least restrictive
> set of permissions, which I believe is fine for our purposes. The problem
> comes when the program calls kernel32.CloseHandle on the non-existent
> handle that was returned by the OpenProcessToken stub.
> Somebody please stop me if there is an easier way of solving this problem.
> It looks like we at least need to create some sort of dummy handle that can
> be removed by kernel32.CloseHandle without causing an error. To do this we
> would need to add an open_process_token request handler to the wineserver
> (perhaps in a new file server/access.c). Another alternative would be to
> create an open_dummy_handle request handler in server/handle.c that could be
> used for any generic dummy handle. The advantage of the first method is
> that if someone decides to implement all the access control functions
> properly, the framework is already in place. Probably some combination of
> the two is best.
> I am willing to do the coding myself, but I'm unsure of the procedures for
> open source development. How do you decide what changes are to be made, how
> do you submit your changes, how do you make sure you don't undo what someone
> else did, and things like that? I also am having trouble finding
> documentation on the make_requests tool.
Just do it as best you can, test it, and if it works for you, make up a
patch against the current cvs and offer it on wine-patches. It is up to
Alexandre Julliard if he will accept it without comment, ignore it
without comment, or tell you what he doesn't like. Patches without an
accompanying ChangeLog entry (to go into <wine>/ChangeLog) or patches
made by diff without -u tend to be silently ignored. If you think about
it, diff -u is the only reasonable format for an open-source project.
I make patches by making a shadow before and after wine direcrory tree
(with cp -Ppar from <wine>) and doing diff -urN before after; no doubt
this is obsoleted by cvs, but it still works. You can also offer your
patch for comments on wine-devel before offering it to wine-patches.
AFAICT, the only doco on make_requests is the file itself (complete with
obsolete comments) and the generated comments in the files it generates.
All requests are defined in server/protocol.def, and make_requests
generates the headers and trace code to suit. AFAICT.
> Thanks for tolerating my newbieness. I'm looking forward to being able to
> start contributing to this great project.
> --Karl Bielefeldt
> kbielefe at hotmail.com
Maybe somebody else will make a better answer. If not, I hope this
More information about the wine-devel