Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.

[Ben Peddell]

On 27/06/2012 7:35 PM, Dmitry Timoshkov wrote:
> Marvin  wrote:
> 
>> === W7PROX64 (64 bit image) ===
>> image.c:2811: Test failed:  0: expected property size 17 or 36, got 44
>> image.c:2811: Test failed:  2: expected property size 144 or 0, got 152
>> image.c:2811: Test failed:  3: expected property size 20 or 0, got 28
>>
>> === TEST64_W7SP1 (64 bit image) ===
>> image.c:2811: Test failed:  0: expected property size 17 or 36, got 44
>> image.c:2811: Test failed:  2: expected property size 144 or 0, got 152
>> image.c:2811: Test failed:  3: expected property size 20 or 0, got 28
> 
> Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail
> delivery problem in the mailing list software, and it is getting pretty
> annoying.
> 

The winehq.org mailserver only allows one SMTP connection per relaying
IP, so emails sent at the same time are likely to be received out of
order unless the relaying mailserver only transfers emails sequentially.

-- 
Ben Peddell
IT Support Bowen, Collinsville and Proserpine Catholic schools
http://klightspeed.killerwolves.net/

Re: Incompatibility in Kernel32

[Ben Peddell]

On 22/06/2012 7:23 PM, robert.van.h...@serioustoys.com wrote:
>>> Is there any reason that you call DeleteFile() on a still being opened file?
>>
>> That's the whole point of this test. The observed behavior is that you can 
>> pass a
>> filename to MsiRecordSetStream, successfully delete the file, and keep on 
>> using the
>> stream.
> 
> I think DeleteFile on a opened file is officially allowed in Windows. 
> Although the MS documentation is vague:
> 
> 
> The DeleteFile function fails if an application attempts to delete a file 
> that is open for normal I/O or as a memory-mapped file.
> 
> The DeleteFile function marks a file for deletion on close. Therefore, the 
> file deletion does not occur until the last handle to the file is closed. 
> Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED.
> 

The first statement is true under the DOS-based Windows systems -
DeleteFile fails with ERROR_ACCESS_DENIED when that file has one or more
open file handles.

The second statement is true under the NT Windows systems - DeleteFile
will fail with ERROR_SHARING_VIOLATION if at least one handle to it
isn't opened with FILE_SHARE_DELETE, and ERROR_ACCESS_DENIED if it has a
memory mapping.

Results from the attached test under Windows 7 x64:

Testing with no sharing, same process and no file mapping
DeleteFile: Failed : 0020
Done

Testing with FILE_SHARE_DELETE, same process and no file mapping
DeleteFile: OK
Done

Testing with no sharing, separate process and no file mapping
DeleteFile: Failed : 0020
Done

Testing with FILE_SHARE_DELETE, separate process and no file mapping
DeleteFile: OK
Done

Testing with no sharing, same process and file mapping
DeleteFile: Failed : 0020
Done

Testing with FILE_SHARE_DELETE, same process and file mapping
DeleteFile: Failed : 0005
Done

Testing with no sharing, separate process and file mapping
DeleteFile: Failed : 0020
Done

Testing with FILE_SHARE_DELETE, separate process and file mapping
DeleteFile: Failed : 0005
Done

Results from the attached test under Windows 98 SE:

Testing with no sharing, same process and no file mapping
DeleteFile: Failed : 0005
Done

Testing with FILE_SHARE_DELETE, same process and no file mapping
CreateFile failed : 0057
DeleteFile: OK
Done

Testing with no sharing, separate process and no file mapping
DeleteFile: Failed : 0005
Done

Testing with FILE_SHARE_DELETE, separate process and no file mapping
CreateFile failed : 0057
DeleteFile: OK
Done

Testing with no sharing, same process and file mapping
DeleteFile: Failed : 0005
Done

Testing with FILE_SHARE_DELETE, same process and file mapping
CreateFile failed : 0057
DeleteFile: OK
Done

Testing with no sharing, separate process and file mapping
DeleteFile: Failed : 0005
Done

Testing with FILE_SHARE_DELETE, separate process and file mapping
CreateFile failed : 0057
DeleteFile: OK
Done

-- 
Ben Peddell
IT Support Bowen, Collinsville and Proserpine Catholic schools
http://klightspeed.killerwolves.net/

#include 
#include 
#include 
#include 

#define dbgprint(...) \
fprintf(stdout, __VA_ARGS__); \
fflush(stdout)

#define dbgerror(...) \
fprintf(stdout, __VA_ARGS__); \
fprintf(stdout, " : %08X\n", GetLastError()); \
fflush(stdout)

void TestDeleteFile(char *infilename, BOOL do_open, BOOL do_share, BOOL do_map, 
char *progname){
  DWORD n;
  static char filename[MAX_PATH];
  static char readback[MAX_PATH];
  void *fileview = NULL;
  HANDLE h = 0;
  HANDLE hmap = 0;

  if (infilename != NULL){
strncpy(filename, infilename, MAX_PATH);
filename[MAX_PATH - 1] = 0;
  } else {
GetTempFileNameA(".", "test", 0, filename);
  }

  if (do_open){
h = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, do_share ? 
FILE_SHARE_DELETE : 0, NULL, OPEN_EXISTING, 0, 0);
if (h == 0 || h == INVALID_HANDLE_VALUE){
  dbgerror("CreateFile failed");
}

if (h != 0 && h != INVALID_HANDLE_VALUE){
  if (!WriteFile(h, filename, sizeof(filename), &n, NULL)){
dbgerror("WriteFile failed after writing %d bytes", n);
  }

  SetFilePointer(h, 0, NULL, FILE_BEGIN);

  if (do_map){
hmap = CreateFileMapping(h, NULL, PAGE_READWRITE, 0, 0, NULL);
if (hmap == 0 || hmap == INVALID_HANDLE_VALUE){
  dbgerror("CreateFileMapping failed");
}

if (hmap != 0 && hmap != INVALID_HANDLE_VALUE){
  fileview = MapViewOfFile(hmap, FILE_MAP_WRITE, 0, 0, 0);
  if (fileview == NULL){
dbgerror("MapViewOfFile failed");
  }
}
  }
}
  }
  
  if (progname != NULL){
_spawnl(_P_WAIT, progname, progname, filename, NULL);
  } else {
dbgprint("DeleteFile: ");
if (!DeleteFile(filename)) {
  dbgerror("Failed");

Re: Incompatibility in Kernel32

[Ben Peddell]

On 21/06/2012 7:11 PM, Dmitry Timoshkov wrote:
> Hans Leidekker  wrote:
> 
>>> Is there any reason that you call DeleteFile() on a still being opened file?
>>
>> That's the whole point of this test. The observed behavior is that you can 
>> pass a
>> filename to MsiRecordSetStream, successfully delete the file, and keep on 
>> using the
>> stream.
>>
>> We currently implement MsiRecordSetStream by creating an in-memory copy of 
>> the
>> stream. As Robert noticed, this will fail if the stream is too large.
>>
>> The idea is to move to an implementation on top of a file handle, but it 
>> should
>> still allow DeleteFile to succeed while the file is in use.
> 
> Thanks, I see. Removing GENERIC_WRITE from flags passed to NtCreateFile by
> DeleteFile makes the test I just sent for that behaviour pass (and that's
> most like a correct fix), but that leads to some other test failures.
> This needs further investigation.

server/fd.c:open_fd() doesn't check that the read-only bit is unset
(i.e. the file is writable) when the DELETE access flag is set.  Thus
DeleteFile() succeeding when the tests expect it to fail.

-- 
Ben Peddell
IT Support Bowen, Collinsville and Proserpine Catholic schools
http://klightspeed.killerwolves.net/
diff --git a/dlls/kernel32/file.c b/dlls/kernel32/file.c
index 18ed188..f69b778 100644
--- a/dlls/kernel32/file.c
+++ b/dlls/kernel32/file.c
@@ -1486,7 +1486,7 @@ BOOL WINAPI DeleteFileW( LPCWSTR path )
 attr.SecurityDescriptor = NULL;
 attr.SecurityQualityOfService = NULL;

-status = NtCreateFile(&hFile, GENERIC_READ | GENERIC_WRITE | DELETE,
+status = NtCreateFile(&hFile, DELETE,
  &attr, &io, NULL, 0,
  FILE_SHARE_READ | FILE_SHARE_WRITE | 
FILE_SHARE_DELETE,
  FILE_OPEN, FILE_DELETE_ON_CLOSE | 
FILE_NON_DIRECTORY_FILE, NULL, 0);
diff --git a/server/fd.c b/server/fd.c
index f3e42bd..ee99e8f 100644
--- a/server/fd.c
+++ b/server/fd.c
@@ -1776,7 +1776,7 @@ struct fd *open_fd( struct fd *root, const char *name, 
int flags, mode_t *mode,
 flags &= ~(O_CREAT | O_EXCL | O_TRUNC);
 }

-if ((access & FILE_UNIX_WRITE_ACCESS) && !(options & FILE_DIRECTORY_FILE))
+if (((access & FILE_UNIX_WRITE_ACCESS) || (access & DELETE)) && !(options 
& FILE_DIRECTORY_FILE))
 {
 if (access & FILE_UNIX_READ_ACCESS) rw_mode = O_RDWR;
 else rw_mode = O_WRONLY;

Re: Command line parameters

[Ben Peddell]

On 12/06/2012 8:59 PM, John Emmas wrote:
> Thanks Hin-Tak and Dan but I think we're at crossed purposes now. 
> Remember that my original question had nothing to do with paths. I
> simply used paths as a convenient example. My question is about
> command-line parameters and (more specifically) about UTF-8 string
> conversion.  Here's an example Consider a Windows user whose
> name is Göran. The UTF-8 byte sequence for this is:-
> 
> 47 C3 B6 72 61 6E   --   (6 bytes)
> 
> whereas Windows would expect something like this (depending on the 
> user's locale):-
> 
> 47 F6 72 61 6E   --   (5 bytes)
> 
> Let's suppose that a Linux app launches a Windows child process 
> (via Wine).  The (Linux) host app needs to pass the string "Göran" 
> as one of the command-line parameters.   Linux uses UTF-8 and will 
> therefore pass the first sequence of bytes to Wine (6 bytes). But
> Windows doesn't understand UTF-8.  A Windows app would expect the
> second byte sequence (5 bytes - or 10 bytes for a Unicode app).

By "Linux uses UTF-8" you're saying that you have a UTF-8 locale active.

> 
> Does Wine carry out the necessary conversion or does it simply
> pass the original byte string unmodified?  That's what I'm trying
> to find out.  Thanks.

Wine first converts the command-line to Unicode according to the
active host locale.

Then any character set conversion from Unicode to ANSI or vice versa
within the application is done according to the active Windows locale.

If the Wine process needs to execute a native process, Wine converts
the command line from Unicode using the active host locale.

The default character set under Linux is ISO-8859-1, while the default
character set under Windows is Windows-1252, which has all of the
printable characters in the same places as in ISO-8859-1, with some
extra printable characters in the C1 (0x80..0x9F) area.

If no host locale is specified (i.e. the locale is POSIX), and the
default Windows locale is used, then the only available characters an
ANSI Windows program will be unable to be passed are the extra
characters in the C1 area.  All unrepresentable characters are
replaced with question marks [?].

-- 
Ben Peddell
IT Support Bowen, Collinsville and Proserpine Catholic schools
http://klightspeed.killerwolves.net/

Re: Command line parameters

[Ben Peddell]

On 12/06/2012 8:59 PM, John Emmas wrote:
> Thanks Hin-Tak and Dan but I think we're at crossed purposes now.
> Remember that my original question had nothing to do with paths. I
> simply used paths as a convenient example. My question is about
> command-line parameters and (more specifically) about UTF-8 string
> conversion.  Here's an example Consider a Windows user whose
> name is Göran. The UTF-8 byte sequence for this is:-
>
> 47 C3 B6 72 61 6E   --   (6 bytes)
>
> whereas Windows would expect something like this (depending on the
> user's locale):-
>
> 47 F6 72 61 6E   --   (5 bytes)
>
> Let's suppose that a Linux app launches a Windows child process
> (via Wine).  The (Linux) host app needs to pass the string "Göran"
> as one of the command-line parameters.   Linux uses UTF-8 and will
> therefore pass the first sequence of bytes to Wine (6 bytes). But
> Windows doesn't understand UTF-8.  A Windows app would expect the
> second byte sequence (5 bytes - or 10 bytes for a Unicode app).

By "Linux uses UTF-8" you're saying that you have a UTF-8 locale active.

>
> Does Wine carry out the necessary conversion or does it simply
> pass the original byte string unmodified?  That's what I'm trying
> to find out.  Thanks.

Wine first converts the command-line to Unicode according to the
active host locale.

Then any character set conversion from Unicode to ANSI or vice versa
within the application is done according to the active Windows locale.

If the Wine process needs to execute a native process, Wine converts
the command line from Unicode using the active host locale.

The default character set under Linux is ISO-8859-1, while the default
character set under Windows is Windows-1252, which has all of the
printable characters in the same places as in ISO-8859-1, with some
extra printable characters in the C1 (0x80..0x9F) area.

If no host locale is specified (i.e. the locale is POSIX), and the
default Windows locale is used, then the only available characters an
ANSI Windows program will be unable to be passed are the extra
characters in the C1 area.  All unrepresentable characters are
replaced with question marks [?].

-- 
Ben Peddell
IT Support Bowen, Collinsville and Proserpine Catholic schools
http://klightspeed.killerwolves.net/

Re: Command line parameters

[Ben Peddell]

On 8/06/2012 4:57 AM, John Emmas wrote:
> FWIW the Windows app launches perfectly if I use execl() in the Linux app - 
> and in fact, this has all worked perfectly for years.  It was only yesterday 
> that I began to wonder if there might be a problem in non-English locales.  
> Up to now, nobody's ever reported a problem (though, as we all know in 
> programming, that doesn't mean there isn't one!)

Wine (and Windows NT OSes) use unicode for the command-line.  Wine would
convert the UTF-8 unix command-line to a UTF-16 Windows command-line.

It is then up to the Windows locale conversion to convert that UTF-16
string to the locale's character set.

-- 
Ben Peddell
IT Support Bowen, Collinsville and Proserpine Catholic schools
http://klightspeed.killerwolves.net/

Re: dosdevices/c not present.. how is it created?

[Ben Peddell]

On 7/12/2011 11:30 AM, Roger Cruz wrote:
> I'm getting the following error when running Wine.
> 
> Using the debugger, I think I found where the problem is:
> 
> 2140int fd = open( unix_name, O_RDONLY | O_DIRECTORY );
[snip]
> When I look in my $WINEPREFIX directory, I can see that the c: directory
> is not there
[snip]
> How does that c: directory get created and by whom?  I have deleted the
> $WINEPREFIX several times already to no avail.

dlls/ntdll/server.c:774
/* create the drive symlinks */

mkdir( "drive_c", 0777 );
symlink( "../drive_c", "dosdevices/c:" );
symlink( "/", "dosdevices/z:" );


What filesystem does $WINEPREFIX live on?

It would appear that symlink() failed on that filesystem.

-- 
Ben Peddell
IT Support Bowen, Collinsville and Proserpine Catholic schools
http://klightspeed.killerwolves.net/

Re: Quick Question

[Ben Peddell]

On 26/09/2011 3:07 PM, Peter Wilson wrote:
> Hi,
> 
> Quick question, might be silly, but is there a version of Wine that can be 
> installed on windows or linux to create apps for Mac?
> 
> I just want to keep my mac clean and try run things in a dev environment, and 
> apple are always so polite to make visualization a pain…
> 
> Thank you very much for you help,
> 
> Kind Regards,
> 
> Peter Wilson
> 

Wine is an implementation of the Windows APIs that will run on Linux and
Mac OS X (and others).

It sounds like you are asking for a binary-compatible implementation of
the Carbon / Cocoa APIs that will run on Linux or Windows, as well as a
Windows or Linux hosted development environment targeted to the Carbon /
Cocoa APIs.

If you are the one developing the application, why not use one of the
cross-platform graphical libraries such as SDL, GTK+, wxWidgets, etc.

If the application uses 3D graphics, many of those cross-platform
graphical libraries also have support for OpenGL.

If you don't want to have to re-compile between your host platform and
your target platform, then you'd have to use something like Java or Mono
to build a platform-independent binary, use Python or similar, or
install Wine on the Mac and create a Windows binary.

-- 
Ben Peddell
IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools
http://klightspeed.killerwolves.net/

Re: crypt32: Cryptic string resources

[Ben Peddell]

On 25/09/2011 6:29 PM, Francois Gouget wrote:
> 
> Are these strings seem to be lacking spaces a bit. Are they real names 
> or mere identifiers? Are they actually translatable?
> 
> dlls/crypt32/crypt32.rc:
> IDS_SPC_SP_AGENCY_INFO "SpcSpAgencyInfo"
> IDS_SPC_FINANCIAL_CRITERIA "SpcFinancialCriteria"
> IDS_SPC_MINIMAL_CRITERIA "SpcMinimalCriteria"

Those names are searched for by CryptFindOIDInfo() when the dwKeyType
argument is CRYPT_OID_INFO_NAME_KEY, and are the values returned in the
pwszName member of the CRYPT_OID_INFO structure.

I can confirm that crypt32 under Windows 7 returns those exact strings.

-- 
Ben Peddell
IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools
http://klightspeed.killerwolves.net/

Re: IPv6 issue on TestBot?

[Ben Peddell]

On 22/09/2011 9:43 PM, Per Johansson wrote:
> 
> 22 sep 2011 kl. 12:14 skrev Michael Stefaniuc:
> 
>> Wow! /66? And that works? While the standard allows for that you "should
>> use /64" which everybody and his dog read it as that is the only thing
>> that needs to work and the only thing that get tested. IPv6 brings back
>> the class-full thinking which everybody has to painfully unlearn once
>> IPv6 catches on...
>>
>> "Safe" prefix length (especially if involving client devices) are:
>> /64 - LAN
>> /126 and /127 - point to point
>> /128 - host routes
> 
> RFC3513 is quite more strict than "should":
> 
>All global unicast addresses other than those that start with binary
>000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
>described in section 2.5.1.  Global unicast addresses that start with
>binary 000 have no such constraint on the size or structure of the
>interface ID field.
> 
> (2001:: has the binary prefix 001). So this might very well be the problem.

If I understand that correctly, if the interface has a hardware address
(48-bit MAC or 64-bit EUI), then the interface ID should be constructed
from that address.

Of course, if you are the administrator of the 2001:888:2000:38::/64
block, then you can assign Scope-Local Interface IDs as you see fit,
just as everyone else does, and as allowed in RFC3513 2.5.1 - however,
the RFCs say the subnet mask needs to be /64.

-- 
Ben Peddell
IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools
http://klightspeed.killerwolves.net/

Re: IPv6 issue on TestBot?

[Ben Peddell]

On 22/09/2011 7:56 PM, Maarten Lankhorst wrote:
> Hey,
> 
> Testbot has 2 ips assigned to it:
> 
>   inet6 addr: 2001:888:2000:38:1000::1/66 Scope:Global
>   inet6 addr: 2001:888:2000:38:1000::2/66 Scope:Global
> 
> Does the ::1 work?
> 
> ~Maarten
> 

Nope.

# traceroute -6 -f 11 -m 15 -T -p443 2001:888:2000:38:1000::1
traceroute to 2001:888:2000:38:1000::1 (2001:888:2000:38:1000::1), 15
hops max, 80 byte packets
11  te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2)  146.532 ms
146.546 ms  146.717 ms
12  * * *
13  * * *
14  * * *
15  * * *

I know I had a little trouble getting ipv6 running on my VMs until I
allowed ICMP6 router-advertisement, neighbour-solicitation and
neighbour-advertisement in through ip6tables.

Does `/sbin/ip -6 route` or `/sbin/route --af inet6` show the proper
routes?

-- 
Ben Peddell
IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools
http://klightspeed.killerwolves.net/

Re: IPv6 issue on TestBot?

[Ben Peddell]

On 22/09/2011 6:24 PM, Maarten Lankhorst wrote:
> Hey,
> 
> On 09/14/2011 12:47 PM, Francois Gouget wrote:
>> Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-(
>> This makes accessing it from my desktop very annoying.
>>
>> $ time wget -4 --quiet http://testbot.winehq.org/ 
>> real 0m2.150s
>> user 0m0.000s
>> sys  0m0.000s
>>
>> $ time wget -6 --quiet http://testbot.winehq.org/
>> ... still stuck after 6+ minutes
>>
>> $ telnet -6 testbot.winehq.org
>> Trying 2001:888:2000:38:1000::2...
>> ... same thing
>>
>>
>> According to http://test-ipv6.com/ my desktop is configured just fine 
>> and I only have trouble with the TestBot.
>>
>> Could this be a firewall problem? (testbot exposing an IPv6 address but 
>> the firewall dropping any IPv6 packets)
>>
>>
>> In the mean time I'm going to use my laptop which is still IPv4 only 
>> :-/
> That ipv6 address is set on testbot, so it ought to work. Does ICMP6 ping 
> work?
> 
> ~Maarten
> 

# traceroute -4 -T -p80 testbot.winehq.org
traceroute to testbot.winehq.org (82.94.219.252), 30 hops max, 60 byte
packets
...
 9  te5-4.swcolo1.3d12.xs4all.net (194.109.12.30)  159.889 ms  159.942
ms  159.868 ms
10  v2.gse.nl (82.94.219.252)  161.955 ms  159.354 ms  164.692 ms

# traceroute -6 -T -p80 testbot.winehq.org
traceroute to testbot.winehq.org (2001:888:2000:38:1000::2), 30 hops
max, 80 byte packets
...
11  te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2)  145.296 ms
145.109 ms  145.817 ms
12  * * *
...
30  * * *

-- 
Ben Peddell
IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools
http://klightspeed.killerwolves.net/

Re: Severe startup latencies for Windows applications run under wine

[Ben Peddell]

On 31/08/2011 3:12 AM, Dan Kegel wrote:
> Try oprofile instead.
> 
> ( A really old intro is at
> http://www.winehq.org/wwn/249#oprofile%20&%20Wine )
> 

Using oprofile, testing 500 iterations of ExitProcess.exe with
msys-bash under wine:

About 2/3 of the active processor time was in wineserver.
About 90% of that was spent in the kernel.
At least 50% of that time was spent in code related related to
ptrace(), which is ultimately called by
wineserver::write_process_memory().

The other 1/3 of the active processor time was in wine-preloader.
About 70% of that was spent in the kernel.

500 iterations took about 100s to complete at about 100% usage of 1
CPU core.

msys-bash uses WriteProcessMemory() to copy 500kB during an emulated
fork.  This equates to about 125000 ptrace(PTRACE_POKEDATA,...)
syscalls, each of which takes about 0.8us on linux 2.6.38.

-- 
Ben Peddell
IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools
http://klightspeed.killerwolves.net/

Re: Severe startup latencies for Windows applications run under wine

[Ben Peddell]

On 08/30/11 10:33, Alan W. Irwin wrote:
> On 2011-08-30 08:20+1000 Ben Peddell wrote:
>> Some things I have seen while investigating:
>>
>> I created a program which had a startup that immediately called
>> ExitProcess to attempt to eliminate most of the initialization of the
>> process being forked.
>>
>> On Windows 7 x64 SP1 on an AMD 5050e:
>> bash.exe takes about 22.2ms to fork.
>> make.exe takes about 8.8ms to fork.
>> cmd.exe takes about 5.9ms to fork.
>>
>> Under wine 1.2.1 on linux 2.6.38 on an AMD 5050e:
>> bash.exe takes about 236ms to fork nothing, and 182ms to fork /bin/true.
>> make.exe takes about 77ms to fork nothing, and 25ms to fork /bin/true.
>> wine-cmd takes about 9ms to fork nothing.
>>
>> Under wine-git on linux 2.6.38 on an AMD 5050e:
>> bash.exe takes about 190ms to fork nothing, and 147ms to fork /bin/true
>> make.exe takes about 71ms to fork nothing and 20ms to fork /bin/true.
>> wine-cmd takes about 9ms to fork nothing.
> 
> Just out of curiosity do you have any explanation of why /bin/true provided
> faster make.exe results than your quick-exiting programme both for
> wine-1.2.1 and wine-git?

I suspect that the fork/exec emulation detects if the executable is a
MSYS executable, and if so, takes a fast path, skipping a lot of the
initialization that the MSYS executable would have done.

> 
>>
>> Even the native bash takes twice as long to fork as make - 1.1ms vs
>> 0.5ms.
>>
>> It looks to me like the fork emulation in MSYS is encountering a
>> bottleneck, and not actual process creation.
> 
> I assume you meant "encountering a _wine_ bottleneck" since clearly
> above your MSYS tests of make.exe and bash.exe on Windows don't have
> the large startup latencies you encounter with wine-1.2 and wine-git.
> 
> How does the MSYS version of make (make.exe that you tried above)
> compare in this regard with the MinGW version of make
> (MinGW/bin/mingw32-make.exe) that specifically excludes everything to
> do with MSYS?  My guess is you will encounter a similar wine
> bottleneck for this case as well, but it is worth verifying that.

I suspect mingw32-make uses fork() emulation when launching MSYS
programs, and CreateProcess() otherwise - the execution time for
msys-echo and msys-true are on par with those under msys-make, and the
execution time for ExitProcess.exe is on par with that under wine-cmd.

> 
> And now you have done a clean comparison with the same software stack
> it is clear that wine-git somewhat reduces the bottleneck compared to
> wine-1.2.  Thus, I expect my own planned clean comparisons to show the
> same.  So I have changed the subject line appropriately.
> 
> Now, if someone could just figure out what the wine bottleneck is that
> is causing these severe start-up latencies for Windows applications

A modification of the timestamp patch from Bernhard Loos should help us
find what calls are taking the longest.

bash: running /bin/echo:
   +0ms:0024:Call KERNEL32.CreateProcessA(bash) => tid 0028
   +8ms:0028:Call KERNEL32.__wine_kernel_init()
  +11ms:0024:Call KERNEL32.WaitForMultipleObjects()
  +21ms:0028:DLLs loading
  +43ms:0028:Process starting
  +45ms:0028:Call KERNEL32.SetEvent() => wake 0024
  +45ms:0024:Call KERNEL32.WriteProcessMemory()
  +45ms:0028:Call KERNEL32.WaitForSingleObject()
write-process-memory 10 times, totalling 500kB
 +134ms:0024:Ret  KERNEL32.WriteProcessMemory()
 +134ms:0028:Ret  KERNEL32.SetFileApisToANSI() ???
 +148ms:0028:Call KERNEL32.CreateProcessA(echo) => tid 002b
 +155ms:002b:Call KERNEL32.__wine_kernel_init()
 +157ms:0028:Ret  KERNEL32.CreateProcessA()
 +158ms:0028:Call KERNEL32.WaitForMultipleObjects()
 +163ms:002b:DLLs loading
 +163ms:002b:Process starting
 +169ms:0028:Call KERNEL32.ExitProcess()
 +172ms:002b:Call KERNEL32.ExitProcess()

bash: running ExitProcess.exe:
   +0ms:0024:Call KERNEL32.CreateProcessA(bash) =>  tid 0034
   +7ms:0034:Call KERNEL32.__wine_kernel_init()
  +11ms:0024:Call KERNEL32.WaitForMultipleObjects()
  +20ms:0034:DLLs loading
  +42ms:0034:Process starting
  +44ms:0034:Call KERNEL32.SetEvent() => wake 0024
  +44ms:0024:Call KERNEL32.WriteProcessMemory()
  +44ms:0034:Call KERNEL32.WaitForSingleObject()
write-process-memory 10 times, totalling 500kB
 +130ms:0024:Ret  KERNEL32.WriteProcessMemory()
 +130ms:0034:Ret  KERNEL32.WaitForSingleObject()
looking at attributes of a whole heap of directories...
 +215ms:0034:Call KERNEL32.CreateProcessA(ExitProcess.exe) => tid 0037
 +221ms:0037:Call KERNEL32.__wine_kernel_init()
 +223ms:0034:Ret  KERNEL32.CreateProcessA()
 +224ms:0034:Call KERNEL32.WaitForMultipleObjects()
 +224ms:0037:Call KERNEL32.ExitProcess()
 +225ms:0034:Call KERNEL32.ExitProcess()

-- 
Ben Peddell
IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools
http://klightspeed.killerwolves.net/

Re: Severe regression in wine startup latencies

[Ben Peddell]

On 29/08/2011 2:37 AM, Alan W. Irwin wrote:
> While I am doing those additional investigations, please consider 
> the question of why there is a huge difference between built-in and
> executable latency for MSYS bash commands under wine.  To start 
> that investigation it would be good to compare the wine results
> for those two cases with the Windows results for those two cases.
> (I assume the two time results for built-in versus executable will
> be fairly similar in the Windows case, but that assumption needs to
> be checked.) I don't have access to Windows myself. Anybody up for 
> doing that simple test and reporting the results back here?  The 
> automatic MinGW/MSYS installer at 
> http://sourceforge.net/projects/mingw/files/Automated MinGW 
> Installer/mingw-get-inst/ makes it easy to install the relevant 
> MinGW/MSYS software on both wine and Windows.

Some things I have seen while investigating:

I created a program which had a startup that immediately called
ExitProcess to attempt to eliminate most of the initialization of the
process being forked.

On Windows 7 x64 SP1 on an AMD 5050e:
* bash.exe takes about 22.2ms to execute a program.
* make.exe takes about 8.8ms to execute a program.
* cmd.exe takes about 5.9ms to execute a program.

Under wine 1.2.1 on linux 2.6.38 on an AMD 5050e:
* bash.exe takes about 236ms to execute a program.
* bash.exe takes about 182ms to execute ${MINGW}/bin/true.
* make.exe takes about 77ms to execute a program.
* make.exe takes about 25ms to execute ${MINGW}/bin/true.
* wine-cmd takes about 9ms to execute a program.

Under wine-git on linux 2.6.38 on an AMD 5050e:
* bash.exe takes about 190ms to execute a program.
* bash.exe takes about 147ms to execute ${MINGW}/bin/true.
* make.exe takes about 71ms to execute a program.
* make.exe takes about 20ms to execute ${MINGW}/bin/true.
* wine-cmd takes about 9ms to execute a program.

Even the native bash takes twice as long to fork as make - 1.1ms vs
0.5ms.

It looks to me like the fork emulation in MSYS is encountering a
bottleneck, and not actual process creation.  Times have actually
improved between 1.2 and current.

-- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home
Hill Catholic schools http://klightspeed.killerwolves.net/

Re: Severe regression in wine startup latencies

[Ben Peddell]

On 29/08/2011 2:37 AM, Alan W. Irwin wrote:
> bash.exe-3.1$ time /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe
> hello
> hello
>
> real0m0.503s
> user0m0.080s
> sys 0m0.020s
>
> Also, I tried
> time (x; x; x; x; x; x; x; x; x; x), where "x" represents the complete
> echo command above, and the result was
>
> real0m5.281s
> user0m0.800s
> sys 0m0.200s
[snip]
>
> While I am doing those additional investigations, please consider the
> question of why there is a huge difference between built-in and
> executable latency for MSYS bash commands under wine.  To start that
> investigation it would be good to compare the wine results for those
> two cases with the Windows results for those two cases.  (I assume the
> two time results for built-in versus executable will be fairly similar
> in the Windows case, but that assumption needs to be checked.) I don't
> have access to Windows myself. Anybody up for doing that simple test
> and reporting the results back here?  The automatic MinGW/MSYS
> installer at http://sourceforge.net/projects/mingw/files/Automated
> MinGW Installer/mingw-get-inst/ makes it easy to install the relevant
> MinGW/MSYS software on both wine and Windows.

Under MSYS 1.0.17 running on Windows 7 x64 SP1:

bash.exe-3.1$ /bin/bash --version
GNU bash, version 3.1.17(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.

bash.exe-3.1$ alias x='/bin/echo.exe -n .'

bash.exe-3.1$ time x
.
real0m0.031s
user0m0.000s
sys 0m0.015s

bash.exe-3.1$ time (x;x;x;x;x;x;x;x;x;x)
..
real0m0.296s
user0m0.075s
sys 0m0.136s

This shows a latency of approximately 2 jiffies for each command - 1
jiffy in Windows is 15.6ms.

-- 
Ben Peddell
IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools
http://klightspeed.killerwolves.net/

Re: iPod synced with iTunes v7.6!

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/08/2010 4:28 PM, Russ Mannex wrote:
> Hello Maarten!
> 
> I read your post on the WineHQ site. I was wondering if you know whether
> I am attempting something that simply will not work yet. I am running
> iTunes 7.7.1 on Wine 1.1.42. These are running on Ubuntu 10.04. iTunes
> is not showing my iPod. I have tried setting an autodetect drive E: to
> /media/IPOD, but iTunes seems to not see it there. Any help will be
> greatly appreciated, even if the answer is "will not work." Thanks.

Apple iTunes uses a kernel-mode device driver (usbaapl.sys) to talk to
the iPod.  It'd be a project all of its own (perhaps bigger than trying
to make a native clone) to try to get iTunes to talk to the iPod under Wine.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxqZWwACgkQTHDAI68NsukS+ACgkRjYFLQB1XOtSH1N3mFOqOX+
m58AoIees4mig4aU1StBaZHy4vbytr+g
=Ez7t
-END PGP SIGNATURE-

Re: [PATCH 2/2] server: Include user groups in file mode calculation when user is file owner

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ben Peddell wrote:
> Alexandre Julliard wrote:
>> You should most likely set the group permissions too in that case.

I have re-submitted, this time setting group mode according to the
permission set of the user's groups.

I forgot to unmask the group bits in try 2, so I have unmasked them in
try 3.

- --
Ben Peddell

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkshwYIACgkQTHDAI68NsumaYQCcC3K/Es3BKXxQcp6ZyI3B2wyu
foIAnA14LqzUhU4pfH5mRPZsTkzF9tYv
=SJ4+
-END PGP SIGNATURE-

Re: [PATCH 2/2] server: Include user groups in file mode calculation when user is file owner

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ben Peddell wrote:
> I think we'd need to implement a security_sid_to_unix_uid function (and
> re-implement the security_unix_uid_to_sid function to complement it) to
> be able to do that properly.

Sorry - that should be security_sid_to_unix_gid and
security_unix_gid_to_sid.

- --
Ben Peddell

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkshqOcACgkQTHDAI68NsunV2gCfWdTNILUbCwPcz4e9+j5pY5P0
wHAAniQ0+RYUPQ1Ba/oa7yPKCnjqdK04
=piHz
-END PGP SIGNATURE-

Re: [PATCH 2/2] server: Include user groups in file mode calculation when user is file owner

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alexandre Julliard wrote:
> "Ben Peddell"  writes:
> 
>> @@ -474,7 +475,9 @@ mode_t sd_to_mode( const struct security_descriptor *sd, 
>> const SID *owner )
>>  if (access & FILE_EXECUTE)
>>  denied_mode |= S_IXUSR|S_IXGRP|S_IXOTH;
>>  }
>> -else if (security_equal_sid( sid, owner ))
>> +else if (security_equal_sid( sid, owner ) ||
>> + (security_equal_sid( user, owner ) &&
>> +  token_sid_present( current->process->token, 
>> sid, TRUE )))
>>  {
>>  unsigned int access = generic_file_map_access( 
>> ad_ace->Mask );
>>  if (access & FILE_READ_DATA)
>> @@ -498,7 +501,9 @@ mode_t sd_to_mode( const struct security_descriptor *sd, 
>> const SID *owner )
>>  if (access & FILE_EXECUTE)
>>  new_mode |= S_IXUSR|S_IXGRP|S_IXOTH;
>>  }
>> -else if (security_equal_sid( sid, owner ))
>> +else if (security_equal_sid( sid, owner ) ||
>> + (security_equal_sid( user, owner ) &&
>> +  token_sid_present( current->process->token, 
>> sid, FALSE )))
> 
> You should most likely set the group permissions too in that case.
> 

I think we'd need to implement a security_sid_to_unix_uid function (and
re-implement the security_unix_uid_to_sid function to complement it) to
be able to do that properly.  Also, we'd need a map of groups and their
direct members, and possibly a map of members and their direct groups to
complement it, to be able to determine the full permission set of the
primary group.

To store additional permissions, we could use POSIX ACLs, Extended
Attributes or special files.  With POSIX ACLs, proper ordering would be
needed - e.g. most restrictive (full deny) through most permissive (full
grant, no deny) to least permissive (no grant, no deny), to ensure users
and groups get the access the security descriptor specifies.

- --
Ben Peddell

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkshm0cACgkQTHDAI68NsunHGwCfTOe0jDyv+spER3tTeyHToUTl
+gcAnRxwedfoxtc5MYeJXpDsLGJK4gKO
=YCdA
-END PGP SIGNATURE-

File owner permissions

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What do you think is the best course of action for setting the owner
permissions on a file:
1. Base the file owner permissions on the DACL permissions of the groups
the file owner is a member of? (My patch or similar)
2. Change the file owner permissions only if they are listed in the
DACL? (Paul Chitescu's patch or similar)
3. Allow the file owner read/write/traverse access (u+rwX) to their own
files by default? (similar to #2)
4. Bypass the file-owner-permissions-cannot-be-overridden issue by
having a third-party trustee (like SYSTEM) own and have full access to
the files.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksUuqAACgkQTHDAI68NsunuQACePqDXjcfvvDXhoEI0rH4WB5Ri
3+YAnjqioPVg9li+Axbo3vUMueqn9phd
=pNiD
-END PGP SIGNATURE-

Re: windows shutdown process

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vincent Povirk wrote:
> In order to find the correct fix for bug 18753, I've been examining
> the shutdown process on Windows. I have written a program that logs
> the messages sent to it, and I've run it on Windows 7. What I found
> was that a shutdown produces the following sequence of events:
> * We get a 0x3b message. DefWindowProc sends a WM_QUERYENDSESSION
> message. We return 1, allowing the session to end.
> * We get another 0x3b message, which leads to a WM_ENDSESSION.
> * Nothing else happens, but for some reason the program exits.
> 
> I added a trace after the message loop returns to see if the program
> gets a WM_QUIT. It doesn't.
> 
> Apparently, my test program was killed.
> 
> I tried changing the window proc so that it loops infinitely when it
> gets WM_ENDSESSION. Windows 7 sees this as "blocking shutdown".
> (Naturally, it responds the same way if I return 0 from
> WM_QUERYENDSESSION.)
> 
> This leads me to believe that Windows 7, when shutting down,
> immediately kills any process that returns from a WM_ENDSESSION
> message.
> 
> Does that seem sane?
> 
> I've posted my test program (source code and .exe file) at
> http://madewokherd.nfshost.com/msgtest.zip, and I'd like to hear if
> other Windows versions behave the same way Windows 7 does.
> 


OS | Terminated on return from WM_ENDSESSION or 0x3B
Windows Vista  | yes
Windows XP | yes
Windows 98 | yes

None of these returned from GetMessage, and no atexit handlers were
called.  Windows 98 did not send the 0x3B message, but terminated the
program after the message handler returned from WM_ENDSESSION.

Windows 98 doing this says Windows NT 4.0 would have done this.

I don't have Windows NT 3.1 to test with, but I think it would have done
the same.

Some references:



Basically, Windows calls TerminateProcess on the process when all of its
window message loop threads have returned from the WM_ENDSESSION (or
wrapping 0x3B) message.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksSIOEACgkQTHDAI68NsukZ3QCfT8oy2uDhQ3whp7nNWjXDEaic
vk4AnReQXvbmzl8AG9r1K5Coj7CRtUem
=v3ge
-END PGP SIGNATURE-

Re: [PATCH] server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 4 Oct 2007, Rob Shearman submitted the patch "server: Add primitive
support for setting and getting the security descriptor of files based
on their Unix permissions.", which calculated the owner permissions
solely based on the grant/deny permissions for the owner's SID.

On 17 Oct 2007, in bug #10067, "Daniel" reported a bug about FAT32
support being broken in 0.9.47 (which included the above patch)

On 21 Oct 2007, Rob Shearman submitted the patch "server: Fix
file_set_sd to handle NULL DACLs.", which added support for setting
permissions from NULL ACLs.

On 21 Nov 2007, Rob Shearman submitted the patch "server: Add primitive
support for setting and getting the security descriptor of files based
on their Unix permissions.", which added the world permissions to the
owner permissions.

On 10 Mar 2009, in bug #17672, Nathan Lineback reported a bug about wine
incorrectly setting permissions when installing Oracle DB.

On 17 Mar 2009, in bug #17776, Richard Hendrikse reported a bug about
FAT32 support being broken.

On 5 Aug 2009, in bug #19588, Ken Sharp reported that wine was setting
the wrong permissions in some cases.

On 10 Nov 2009, in bug #20643, Marshall Davis reported that wine was
removing owner permissions when World of Warcraft was giving only the
users group permission to access the World of Warcraft directory.

On 17 Nov 2009, I posted an initial patch here to take the permissions
of the groups the user is a member of when calculating the UNIX mode.

Rob Shearman replied:
> While I agree that there is a problem that needs to be fixed, I'm not
> sure this is the right approach. I think you need to take a step back
> and consider the meanings of the different SIDs in a token by default
> and how they map wine running inside the Unix permissions model.

Later on 17 Nov 2009, I revised the patch to only look at the user's
groups if the user was the owner of the file.

If permissions should be revoked from a user when (1) they are the owner
of the file, (2) they are not a trustee in the file's security
descriptor, and (3) they are removed from all groups in the file's
security descriptor, then there needs to be some other way of storing
the owner of the file and the security descriptor in the filesystem
(such as POSIX ACLs), and the owner in the security descriptor cannot be
the UNIX owner of the file, as the UNIX owner permissions cannot be
overridden by POSIX ACLs.

In the meantime, the owner of the file cannot access the file when they
are not a trustee in the security descriptor, even if token_access_check
says they should be able to access the file.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksO/KUACgkQTHDAI68NsunTzwCfVdptQ8sFkFr42r2KOJjvbE2p
U7YAoIGowA5ncsgts+p+twCxNDrEedKd
=knqg
-END PGP SIGNATURE-

Re: FAT32 support (was: [RFC] Handle process token groups in server/file.c::sd_to_mode)

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Chitescu wrote:
> How should server/file.c sd_to_mode() deal with filesystems that don't support
> full POSIX ownership and access permissions? It is quite popular to mount FAT
> filesystems - either from a removable media or a partition shared with a
> Windows installation.

A workaround for the moment on linux would be to use the uid=
option when mounting the a FAT filesystem, as the linux vfat filesystem
driver basically ignores chmod (except for the u+w bit) when the user
executing chmod is the owner of the filesystem.  I don't know if Mac OS
X, *BSD or Solaris do the same.

(tracing using procmon and setacl) NtQuerySecurityObject and
NtSetSecurityObject return STATUS_INVALID_DEVICE_REQUEST on Windows XP
when attempting to get or set a security descriptor on a FAT filesystem.

(musing) I wonder if it'd be possible to have a special SD pointer (such
as -1 or a special SD_INVALID_DEVICE_REQUEST descriptor) in a wineserver
object to say that neither the object nor any of its children can hold
security descriptors?  After all, you cannot put volume mount points on
a FAT filesystem, so nothing under a FAT filesystem would be able to
hold a security descriptor.  obj->get_sd() and obj->set_sd() would then
be made to return STATUS_INVALID_DEVICE_REQUEST on such an object.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksJ6dQACgkQTHDAI68NsukvQQCePLlkXB7aT0HrrTUjarkdNAiv
OcYAn3hYtfTwBveT/6ltNIiO8b2oD7ZH
=bAgm
-END PGP SIGNATURE-

Re: FAT32 support (was: [RFC] Handle process token groups in server/file.c::sd_to_mode)

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Chitescu wrote:
> How should server/file.c sd_to_mode() deal with filesystems that don't 
> support 
> full POSIX ownership and access permissions? It is quite popular to mount FAT 
> filesystems - either from a removable media or a partition shared with a 
> Windows installation.

FAT32 support

To support this, I think the following would need to be done:

* Possibly split out and extended the filesystem type autodetection code
in dlls/ntdll/file.c::get_device_info() to autodetect the filesystem's
ability to hold ACLs

* Implement NtQueryVolumeInformationFile(FileFsAttributeInformation)
  - this has flags such as:
* FILE_PERSISTENT_ACLS: Persistent ACLs (NTFS vs FAT32),
* FILE_CASE_SENSITIVE_SEARCH: case-sensitive search (POSIX)
  - this also has the name of the filesystem (e.g. NTFS, FAT32).

* Implement the honouring of FILE_PERSISTENT_ACLS in
NtQuerySecurityObject, NtSetSecurityObject

* Possibly add a filesystem type configuration option to winecfg
(separate to media type).

* Possibly honour the media and filesystem type settings as configured
by winecfg.


> Furthermore, there could be symlinks to such files so filesystem capability 
> should be detected somehow from the file itself.

Volume Mount Point support

* Possibly extend dosdevices to include devices for Volume Mount Points.

* Possibly implement detection of symbolic links leading to mount points
as volume mount points - i.e. create \Device entries for mount points,
and redirect Volume Mount Point targets to those devices.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksFo3YACgkQTHDAI68NsunoigCfTQQQI6UpD8kCOBL5G83hzjgh
ahMAniPZq9CsVOnZHyko/1Hucc362Wql
=oWXW
-END PGP SIGNATURE-

Re: [RFC] Handle process token groups in server/file.c::sd_to_mode

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have just tested this patch with the World of Warcraft launcher
(couldn't before due to a mismatch between 32-bit and 64-bit jpeg
versions, and Gentoo masking out jpeg).

After SetFileSecurityW (L"H:\\Games\\World of Warcraft", 0x4, 0x1697c8)
with the ACL "(A;OICI;GA;;;BU)", the permissions on the World of
Warcraft directory are rwxr-x---, and the Launcher successfully starts
the Downloader.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksDHQUACgkQTHDAI68Nsumt2ACdHX9emdsvGPkfpGVfky9WRuvY
DR4AoIP0qHiR4Kls1tIcKX+Wed+UwoA8
=iAmD
-END PGP SIGNATURE-

Re: [RFC] Handle process token groups in server/file.c::sd_to_mode

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Chitescu wrote:
> Hi!
>
> How should server/file.c sd_to_mode() deal with filesystems that don't
> support full POSIX ownership and access permissions? It is quite
> popular to mount FAT filesystems - either from a removable media or a
> partition shared with a Windows installation.
>
> Furthermore, there could be symlinks to such files so filesystem
> capability should be detected somehow from the file itself.

The only portable way I can think of is having certain "drives" marked
as e.g. FAT32 (instead of NTFS), and having
dlls/ntdll/sec.c::NtSetSecurityObject() either fake success, or (with
support from other areas) do whatever it does on FAT32 (and I don't know
what that is).

The fstatvfs portability function in libport only reports filesystem
space, and not type or id, so that cannot be used to portably detect
what type of filesystem the file sits on.

> Since recently I am unable to patch WoW since it started to call
> SetFileSecurity on the program directory which is located on a FAT32
> partition. Everything appears owned by root but with rwxrwxrwx access.
> Wine tries to set ---rwx--- which is, to say the least, not commonly
> seen.
>
> http://bugs.winehq.org/show_bug.cgi?id=20643

The World of Warcraft Launcher tries to set the directory to Full Access
only to the Users group, which wine currently does put the user in.
This is a World of Warcraft bug in that it also affects Windows users.
However, it exposes a shortcoming in the ACL handling in wine.

The setting to ---???--- is one of the bugs I am hoping to fix with this
patch.  Currently, server/file.c::sd_to_mode() only honours owner and
world permissions, and does not look at what groups the owner is a
member of.

After this patch, the Launcher (through wine) should set the permissions
to rwx???--- if the user owns the directory.

I can see multiple bug reports in bugs.winehq.org involving either
programs removing the owner permissions or FAT32 mounts not working due
to failed permission setting.


  Wine denies access to Oracle Client install folder

  Problem with wine creating folders on installs

  Wine is setting incorrect permissions in some instances

  Steam Failed to set file attrbutes

  Installing on Fat32 partitions seems to be impossible nowadays

  InstallShield fails with "Access Denied" dialog when trying to install
to FAT32 volume

  World of Warcraft launcher tries to change folder permissions (Not a
Wine bug)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksCnvIACgkQTHDAI68NsumTLwCdGcE4Pd52d/P1yAZThqSSEefk
Z9cAnRjBdMy0TbF0ET1NGKm7Nbs+lx1h
=+HHN
-END PGP SIGNATURE-

Re: [RFC] Handle process token groups in server/file.c::sd_to_mode

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rob Shearman wrote:
> While I agree that there is a problem that needs to be fixed, I'm not
> sure this is the right approach. I think you need to take a step back
> and consider the meanings of the different SIDs in a token by default
> and how they map wine running inside the Unix permissions model. For
> example, maybe these mappings make sense:
> 
> security_local_sid -> user + group + others
> security_interactive_sid -> user + group + others
> alias_users_sid -> user + group + others?
> 
> Now it's likely that the bugs you are trying to fix are trying to set
> the SD for a file to alias_admins_sid or alias_users_sid. The mapping
> for alias_admins_sid is less clear - one could argue that all Wine
> users on a given system would present themselves as admins to apps,
> but then again the apps may be restricting permissions on a file
> because it contains sensitive data and should only be shared with
> other admins (which would be trusted as such, unlike other users on a
> system).
> 

Currently, the wine NT DACL -> unix permission code works as follows:
* The permissions start as deny all.
* If the world SID is granted a permission, then that permission is
added to both owner and others.
* If the owner SID is explicitly granted a permission, then that
permission is added to owner.
* If the world SID is denied a permission, then that permission is
removed from both owner and others.
* If the owner SID is explicitly denied a permission, then that
permission is removed from owner.

This means that if neither owner nor world are listed in the NT DACL,
the owner of the file is denied all permissions on that file, even if
they would have been granted access by one of their groups.

Windows Access Control Lists act as a series of grant/deny Access
Control Entries, and the entire Access Control List must be consulted to
determine the rights of the user.  If none of the user, the user's
groups or the world SID are mentioned in the DACL, then that user is
denied all permissions.  No SIDs are treated specially (not even SYSTEM).

Unix permissions and Access Control Lists act as a set of definitive
Access Control Entries, and the first Access Control Entry that applies
to the user or one of their groups is used to determine the rights of
the user. The superuser is treated specially, and is always granted
permission (unless squashed by the filesystem or a security module).

As the owner permission is consulted before any entries in the ACL, the
owner permission cannot be overridden by an entry in the ACL.

I have modified my patch to only check the groups in the process token
if the owner of the process is the owner of the file.

This patch:
* in server/token.c:
  * exposes token_sid_present(), which tests whether an SID is present
in the token.
* in server/file.c::sd_to_mode():
  * Sets the local boolean variable user_is_owner if the owner of the
process and the owner of the file are the same.
  * Denies permissions from the owner of the file if user_is_owner is
true and the SID denying permissions is present in the token.
  * Grants permissions to the owner of the file if user_is_owner is true
and the SID granting permissions is present in the token, and is not a
deny-only SID.

The patch seeks to ensure that the owner of the file is granted and/or
denied permissions based on the permissions of their groups. At the
moment, it only does this if the owner of the file is also the owner of
the process, as I don't know how to look up the groups of other users.

The only other way I can see of doing this is to pre-process the SID and
add a grant and/or deny ACE for the owner based on the access given by
their groups.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksB7AoACgkQTHDAI68NsumA4wCfc61LXxavFTe82jXC2DjTMrXH
iN0An3+hI0dFBYbsb7hY3JRyjXTD0eD3
=Ch74
-END PGP SIGNATURE-
 server/file.c |7 +--
 server/security.h |1 +
 server/token.c|2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/server/file.c b/server/file.c
index a74de14..db9dd5f 100644
--- a/server/file.c
+++ b/server/file.c
@@ -461,6 +461,7 @@ mode_t sd_to_mode( const struct security_descriptor *sd, 
const SID *owner )
 if (present && dacl)
 {
 const ACE_HEADER *ace = (const ACE_HEADER *)(dacl + 1);
+int user_is_owner = security_equal_sid( owner, token_get_user( 
current->process->token) );
 ULONG i;
 for (i = 0; i < dacl->AceCount; i++, ace = ace_next( ace ))
 {
@@ -485,7 +486,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd, 
const SID *owner )
 if (access & FILE_EXECUTE)
 denied_mode |= S_IXUSR|S_IXGRP|S_IXOTH;
 }
-else if (security_equal_sid( sid, owner ))
+else if (security_equal_sid( sid, owner ) ||

[RFC] Handle process token groups in server/file.c::sd_to_mode

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This proposed patch (which I believe will contribute toward solving bugs
17672, 19588 and 20643, and any others where the permissions are set too
restrictive) exposes the token_sid_present call in token.c,
and uses it to check the SIDs in the security descriptor against those
in the process token.

Are there any changes anyone can think of before I submit it to
wine-patches?

Is there a better (already exposed) way of checking a SID against the
process token's group list?

- 
 server/file.c |6 --
 server/security.h |1 +
 server/token.c|2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksBcpAACgkQTHDAI68Nsuny6ACfXu3vvWS6O27Z/mfozb4e/ZMG
MYQAoItP8P75a3l54TYrLnQbk7lNyaaQ
=7QsU
-END PGP SIGNATURE-
 server/file.c |6 --
 server/security.h |1 +
 server/token.c|2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/server/file.c b/server/file.c
index a74de14..793c24a 100644
--- a/server/file.c
+++ b/server/file.c
@@ -485,7 +485,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd, 
const SID *owner )
 if (access & FILE_EXECUTE)
 denied_mode |= S_IXUSR|S_IXGRP|S_IXOTH;
 }
-else if (security_equal_sid( sid, owner ))
+else if (security_equal_sid( sid, owner ) ||
+ token_sid_present( current->process->token, sid, 
1 ))
 {
 unsigned int access = generic_file_map_access( 
ad_ace->Mask );
 if (access & FILE_READ_DATA)
@@ -509,7 +510,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd, 
const SID *owner )
 if (access & FILE_EXECUTE)
 new_mode |= S_IXUSR|S_IXGRP|S_IXOTH;
 }
-else if (security_equal_sid( sid, owner ))
+else if (security_equal_sid( sid, owner ) ||
+ token_sid_present( current->process->token, sid, 
0 ))
 {
 unsigned int access = generic_file_map_access( 
aa_ace->Mask );
 if (access & FILE_READ_DATA)
diff --git a/server/security.h b/server/security.h
index 39b1d2f..33cf5da 100644
--- a/server/security.h
+++ b/server/security.h
@@ -55,6 +55,7 @@ extern int token_check_privileges( struct token *token, int 
all_required,
 extern const ACL *token_get_default_dacl( struct token *token );
 extern const SID *token_get_user( struct token *token );
 extern const SID *token_get_primary_group( struct token *token );
+extern int token_sid_present( struct token *token, const SID *sid, int deny);
 
 static inline const ACE_HEADER *ace_next( const ACE_HEADER *ace )
 {
diff --git a/server/token.c b/server/token.c
index ce896ac..461e79d 100644
--- a/server/token.c
+++ b/server/token.c
@@ -776,7 +776,7 @@ int token_check_privileges( struct token *token, int 
all_required,
 return (enabled_count > 0);
 }
 
-static int token_sid_present( struct token *token, const SID *sid, int deny )
+int token_sid_present( struct token *token, const SID *sid, int deny )
 {
 struct group *group;
 




wine-sd_to_mode-group-check.patch.sig
Description: Binary data

Re: [RFC] Extended Attributes for Dos Attributes, Creation Time, etc.

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dan Kegel wrote:
> Hi Ben,
> did you see
> http://bugs.winehq.org/show_bug.cgi?id=15679
> http://www.winehq.org/pipermail/wine-patches/2009-October/079842.html
> ?
> 
> IMHO the way the Samba sources merged the fd and filename
> version of the calls makes for less duplication of code.
> (I tried to do it the other way first, and it seemed ugly.)
> - Dan

I saw that, and that's at least part of why I created that extended
attribute portability patch for libport.  Serves as one location to fix
any bugs in it, or extend the support to other platforms.

I noticed that the portability functions in libport were each in their
own separate C file, and that's why I did it like that.

I can see what you're saying about duplication of code, and it would
make sense to merge the xattr portability functions into a single C file
(e.g. xattr.c).

If there's a better place for the xattr portability code, please say so.

I know it's unlikely to be merged until a few units actually start using
extended attributes.

Thinking about the NT ACL storage issue (brought up by bug #20643),
rather than using xattrs for that, POSIX ACLs would be a better target.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksBFp8ACgkQTHDAI68NsukTqQCfcFNsC+1o0YjSbBf9kHW3w0nF
2IkAnicyCrgnmqZl+Qd+DAmke+C0yHVA
=ANKR
-END PGP SIGNATURE-
<>

[RFC] Extended Attributes for Dos Attributes, Creation Time, etc.

[Ben Peddell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What are your thoughts on using Extended Attributes for items such as:
* Dos Attributes (like samba's "store dos attributes = yes")
* File Creation Times (like samba's proposed user.crtime)
* An option for alternate storage of NT ACLs (like samba's "vfs object =
acl-xattr")

Are Extended Attributes acceptable?
Or should they never touch the wine source?

Where would the portability functions for Extended Attributes on Linux,
Mac OS X, FreeBSD and Solaris belong?  I would think in libport.

Attached is a patch to add extended attribute portability functions for
fgetxattr, fsetxattr and fremovexattr to libport.

Please give me any comments on this patch, and the idea of using
extended attributes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksAm/4ACgkQTHDAI68NsumFzwCbBDcRbB8kFXroLeskA+hzgswu
i0UAn3NHbau8AjSgtoruggBH3py+orcZ
=tEvP
-END PGP SIGNATURE-
>From 2ef84c7f8c849db18ce15366e72c6787fa83597d Mon Sep 17 00:00:00 2001
From: Benjamin Peddell 
Date: Mon, 16 Nov 2009 01:23:28 +1000
Subject: [PATCH] Add Extended Attribute support to libport

---
 configure|  178 ++
 configure.ac |   45 
 include/config.h.in  |   39 ++
 include/wine/port.h  |   36 +
 libs/port/Makefile.in|3 +
 libs/port/fgetxattr.c|   96 +
 libs/port/fremovexattr.c |   75 +++
 libs/port/fsetxattr.c|  102 ++
 8 files changed, 574 insertions(+), 0 deletions(-)
 create mode 100644 libs/port/fgetxattr.c
 create mode 100644 libs/port/fremovexattr.c
 create mode 100644 libs/port/fsetxattr.c

diff --git a/configure b/configure
index 15652b4..c9322b3 100755
--- a/configure
+++ b/configure
@@ -5747,6 +5747,7 @@ for ac_header in \
sys/errno.h \
sys/event.h \
sys/exec_elf.h \
+   sys/extattr.h \
sys/filio.h \
sys/inotify.h \
sys/ioctl.h \
@@ -5782,6 +5783,7 @@ for ac_header in \
sys/utsname.h \
sys/vm86.h \
sys/wait.h \
+   sys/xattr.h \
syscall.h \
termios.h \
unistd.h \
@@ -12084,6 +12086,9 @@ for ac_func in \
chsize \
dlopen \
epoll_create \
+   extattr_delete_fd \
+   extattr_get_fd \
+   extattr_set_fd \
ffs \
finite \
fnmatch \
@@ -12105,6 +12110,7 @@ for ac_func in \
lstat \
memmove \
mmap \
+   openat \
pclose \
pipe2 \
poll \
@@ -12137,6 +12143,7 @@ for ac_func in \
tcgetattr \
thr_kill2 \
timegm \
+   unlinkat \
usleep \
vsnprintf \
wait4 \
@@ -12262,6 +12269,81 @@ fi
 
 fi
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing 
fgetxattr" >&5
+$as_echo_n "checking for library containing fgetxattr... " >&6; }
+if test "${ac_cv_search_fgetxattr+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_func_search_save_LIBS=$LIBS
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char fgetxattr ();
+int
+main ()
+{
+return fgetxattr ();
+  ;
+  return 0;
+}
+_ACEOF
+for ac_lib in '' attr; do
+  if test -z "$ac_lib"; then
+ac_res="none required"
+  else
+ac_res=-l$ac_lib
+LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
+  fi
+  if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_search_fgetxattr=$ac_res
+fi
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext
+  if test "${ac_cv_search_fgetxattr+set}" = set; then :
+  break
+fi
+done
+if test "${ac_cv_search_fgetxattr+set}" = set; then :
+
+else
+  ac_cv_search_fgetxattr=no
+fi
+rm conftest.$ac_ext
+LIBS=$ac_func_search_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_fgetxattr" >&5
+$as_echo "$ac_cv_search_fgetxattr" >&6; }
+ac_res=$ac_cv_search_fgetxattr
+if test "$ac_res" != no; then :
+  test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
+
+fi
+
+
+for ac_func in \
+   fgetxattr \
+   fremovexattr \
+   fsetxattr \
+
+do :
+  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
+ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
+eval as_val=\$$as_ac_var
+   if test "x$as_val" = x""yes; then :
+  cat >>confdefs.h <<_ACEOF
+#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+done
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing 
gethostbyname" >&5
 $as_echo_n "checking for library containing gethostbyname... " >&6; }
 if test "${ac_cv_search_gethostbyname+set}" = set; then :
@@ -12616,6 +12698,102 @@ $as_echo "#define