Access Control Functions
ghicks at ihug.com.au
Fri Nov 30 23:36:04 CST 2001
Does this mean wine has a new author working on it?
lawson_whitney at juno.com wrote:
> 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
> > website).
> 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