Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
On Sunday 25 January 2009 12:39:22 Dmitry Timoshkov wrote: Guillaume SH gsh.debianli...@gmail.com wrote: As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team. That comes from a simple understanding that win32 API behaviour is defined by Microsoft, not by anybody else. Having a NULL check, or even an exception handler in an API is not fix for a defect as you might imply, that's actually good that applications crash when they pass invalid data. Wine needs to handle invalid case only when Windows does have them, and only if there are applications depending on that behaviour. If you whish to fix win32 API, make Microsoft hire you. What about an assertion right before the following line: *lpTransferred = lpOverlapped-InternalHigh; This way it will still crash in the same circumstances, but will make it easier to debug programs.
Re: running msys under wine
On Saturday 10 January 2009 01:05:07 David Laight wrote: On Fri, Jan 09, 2009 at 06:39:27PM +, Luke Kenneth Casson Leighton wrote: further up the strace files, i'm looking at the biggest offender and it looks like it's reading files one byte at a time. Certainly a normal unix shell has to read input (from stdin) byte by byte since it never knows when it might have to fork a process passing stdin through - and the child needs the correct file offset. (And the unix kernel doesn't have a 'read until newline' for files.) If stdin is seekable or mapable there are other options, but that is difficult to detect and code for. David Hi, I don't think this is true. When the shell forks to create a child, it doesn't have to give the child the same standard file descriptors - rather it creates pipes, and it passes stdin to the child by reading its own stdin than writing the data to the child's stdin pipe. This way it can filter the input (like for control sequences). So, if it has any excess input data when it creates a child, it simply writes that data to the stdin pipe first. That is how I think things are and should be done. Ambroz
Re: [1/4] winemenubuilder: move path normalization to Process_Link and Process_URL
On Monday 01 December 2008, Francois Gouget wrote: On Sun, 30 Nov 2008, Ambroz Bizjak wrote: [...] To allow that, I've modified winemenubuilder to record created shortcuts to registry, and my service will obtain and maintain the list of .lnk/url files from there. The general idea is good, but I don't think you should store these paths in the registry. Instead the daemon should ask for file change notifications for the relevant special folders (CSIDL_STARTMENU, etc) and act accordingly when a .lnk or .url file gets added / deleted somewhere in thes directories. In that case the daemon would still have to store the list of known files, so that if a shortcut is deleted while Wine is not running, or if my service is not running at that particular time, its removal could still be detected. Another issue with your suggestion is that it would complicate watching. Assuming the notification functions don't work everywhere, and they may have race conditions*, we still have to poll for changes - that means recursing the folders. Last, my service does not yet remove created icons. With the current design, it is largely a matter of also recording the icon names to registry in winemenubuilder. It would be quite hard and hackish to locate the icon from the .desktop file. It would even be hard to get the logical location of the shortcut only from the location of the .lnk, because functions in menubuilder that do that require the file to exist. * I once deleted two watched files in some folder, but only one notification was generated, and my program found only one of the files missing.
Re: Patchwatcher security improvements
Francois Gouget wrote: This seems like an almost perfect task for a virtual machine: * set up you virtual machine to taste * take a snapshot * to test a patch, fire up the virtual machine * have it test the patch * after the test or when it times out, revert it to the snapshot * rinse (done in the step above), repeat This could be done with VirtualBox, but maybe other alternatives based on Xen or KVM or some such would be better. The main issue I see with this is that the OpenGL / DirectSound tests will not run on the real hardware (as usual), but maybe a Xen-like approach could help there. It would also make it easy to test on FreeBSD / Solaris, at least if based on something like VirtualBox (not sure about the Xen-like approaches). Seems like a good idea. I suggest only to use Linux as the host OS and run guests with KVM or VirtualBox, or even UML for Linux builds. Then we can run any OS that uses X as a guest and configure it to use the host's X display (through the virtual network). This should theoretically allow OpenGL through the XGL protocol, but VMGL can also be used if it doesn't work well. And sound hardware would be emulated by the VM software. I think I'll try getting a small Gentoo system to run in UML with a read-only root fs and make it boot as fast as possible. To try a patch, I would give it read access to the master Wine tree on the host, it would copy it to a writable temp folder and try it out. After it's finished or if the external timeout elapses, the UML process will be terminated and all of its writable storage will be reverted.
Re: Patchwatcher security improvements
Dan Kegel wrote: So the slave can be in another real machine, another virtual machine, or running as another user; anything as long as it can get read/write access to its subdirectory of the shared directory. The problem with your design right now is that you want to run the slave in some isolated environment and expect it to be secure. The build slave itself is a mission-critical process and putting it in a quarantine to run together with untrusted code allows malicious patches to interfere with its operation. This means an attacker can just kill it from inside his patch, causing the whole patch building operation to fail, or corrupt the baseline tree, or send hundreds of fake emails through the slave interface. So I plan to run the build slave itself in a trusted environment, but make it quarantine individual build operations (similar to my previous design with user switching). This way the impact of an attack is highly limited - all it can theoretically do is fake his own patch results.
Patchwatcher security improvements
Hi, I've abandoned my chroot aproach to improving security in patchwatcher. Instead I've implemented the ability to run untrusted code as a user different than the one running patchwatcher. This is because creating a chroot where Wine could be compiled and tested proved to be too difficult and platform-dependent. I've also added external time limits for running untrusted code. This as a whole should help prevent individual patches from stalling the patch watching process. It very easy to set up. All you need is a low-privileged user (but enough to run the tests, e.g. audio, video groups) and an empty folder where you can write but this user can only read (not your home folder, it shouldn't have access there anyway). To use it, start with a clean patchwatcher and adjust the variables in the patchwatcher.sh, then run patchwatcher.sh intialize. It will instruct you to run some commands as root (setuid the wrapper). Run initialize again and it should build wine and run baseline tests. Then you can test it by putting a patch in patches/ and issuing the try_one_patch command. To start watching use the continuous_build command. Patch is attached. patchwatcher-crossuser10.patch.bz2 Description: application/bzip
re: Patchwatcher security improvements
Interesting.One of my goals is to support Solaris and BSD; have you tried your stuff there? Not yet, but that stuff is pretty generic, so it shouldn't be hard to get it to work. I'm surprised you had to give up on the chroot... I was planning on trying to run just wine-slave.sh in a chroot jail, since it's the only part that would actually try to run any part of the wine build system. Creating the chroot itself is really hard and has to be done for each platform separately. The basic system and also all development tools and Wine dependencies have to be copied properly. And there are the tests with their own bunch of requirements. In the end you would end up with a chroot that is not much different from the base system itself. And it doesn't really bring many security benefits. Many potentially insecure interfaces have to be exposed anyway (/proc, X server with OpenGL, sound hardware). If a clean and dedicated system is used and permissions are properly configured, running stuff on the base system shouldn't really be a problem. Furthermore, using some advanced access control system (like SELinux) would probably be easier to configure and more efficient.
Re: Patchwatcher security improvements
Also, it's possible some of your changes won't be needed after the refactoring... I plan to run wine-slave as a different user anyway... That doesn't solve much; although in may look clean, it is not secure. The user should have a limited amount of resources to work with. Your way, for example, it can write the whole master Wine tree. With my patches, the master tree is read-only for the user, and it only has its own copy to work with which is never used again. I plan to further improve things. In particular, killing stall processes is not implemented securely now. As I have already mentioned, additional access control is needed to produce a fully solid system. For example, disk access should be limited (think about world-writable folders and stuff like ~/.bashrc), and memory usage should be limited as well (could patchwatcher get killed when the patch starts consuming memory?). Considering the refactoring, I see you are just some moving stuff into its own file; I can easily adjust my code.
Re: Patch checking robot coming
I've written some code for the chroot, though it has proven to be harder than I taught it would, especially because of all the development tools and libraries that need to be copied into the chroot. Right now it will only work on Gentoo, other distributions will require some fine-tuning of paths, especially the toolchain. Dan, if you tell me which distro you use, I'll try to get it working there as well. To use it, you first need a second user in the system (not the one you're using!) that has read-access to files you create with default permissions (but no write access). Specify that user in the file config and run patchwatcher.sh initialize_chroot. If everything goes well you will be able to get a shell inside the chroot with patchwatcher.sh chroot-shell or patchwatcher.sh chroot-shell-owner after running some commands displayed as root. After having a working chroot, use the initialize_tree command to setup the wine source (it's inside the chroot), and the run option to start continuous building. patchwatcher-chroot1.patch Description: Binary data
Re: Patch checking robot coming
Dan Kegel wrote: Sounds great. Want to implement that and send it my way? It'll take me a while to get the kinks worked out of the script, it'd be nice to have a hand with the chroot. - Dan OK, I'll try it. I have a lot of experience with the OS's architecture so it should be ready soon.
Re: Patch checking robot coming
Dan Kegel wrote: What I have so far is a script that watches wine-patches and applies each patch to current git, then builds, Just where are you going to run that? To me, a script that builds just every patch is a serious security flaw; I suppose it wouldn't be very hard for someone to send a naughty patch that would take control of your machine. Something like editing a Makefile. I suggest you make it build patches in a chroot as a regular user, and copy over the chroot from a template every time a new patch is being built.
