From Alan.Bateman at oracle.com Fri Mar 1 07:02:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Mar 2013 15:02:10 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <513094F3.4000701@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> Message-ID: <5130C2F2.8070604@oracle.com> On 01/03/2013 11:45, Alexey Utkin wrote: > > That is possible, but includes pre-requirements for installed MS > tools. That is not a good idea. I agree. > > New version of the fix was prepared. > Bug description: > http://bugs.sun.com/view_bug.do?bug_id=7190897 > https://jbs.oracle.com/bugs/browse/JDK-7190897 > The suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7190897/webrev.01/ This looks much better, thank you. A minor point is that in checkAccessMask then you could call OpenThreadToken before the try/finally. That way you wouldn't need to check hToken. Otherwise I think this is good to go and it's nice to finally fix this issue. -Alan From Alan.Bateman at oracle.com Mon Mar 4 03:51:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 11:51:49 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <513469F8.4060606@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> <513469F8.4060606@oracle.com> Message-ID: <51348AD5.8080301@oracle.com> On 04/03/2013 09:31, Alexey Utkin wrote: > Alan, > Do you agree with >> /** >> * Check the access right against the securityInfo in the current >> thread. >> */ >> static boolean checkAccessMask(long securityInfo, int accessMask, >> int genericRead, int genericWrite, int genericExecute, int >> genericAll) >> throws WindowsException >> { >> int privilegies = TOKEN_QUERY; >> long hToken = OpenThreadToken(GetCurrentThread(), >> privilegies, false); >> if (hToken == 0L && processTokenWithDuplicateAccess != 0L) >> hToken = DuplicateTokenEx(processTokenWithDuplicateAccess, >> privilegies); >> >> boolean hasRight = false; >> if (hToken != 0L) { >> try { >> hasRight = AccessCheck(hToken, securityInfo, accessMask, >> genericRead, genericWrite, genericExecute, >> genericAll); >> } finally { >> CloseHandle(hToken); >> } >> } >> return hasRight; >> } > implementation approach? Can the handle to the token (hToken) be 0? In my comment I was suggesting: long hToken = OpenThreadToken(...); try { ... } finally { CloseHandle(hToken); } but that doesn't work if OpenThreadToken succeeds with a handle of 0. If 0 is not possible then there are a few other clean-ups that we could do at a later time. -Alan From Alan.Bateman at oracle.com Mon Mar 4 03:56:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 11:56:53 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <51348AD5.8080301@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> <513469F8.4060606@oracle.com> <51348AD5.8080301@oracle.com> Message-ID: <51348C05.9040406@oracle.com> On 04/03/2013 11:51, Alan Bateman wrote: > > > but that doesn't work if OpenThreadToken succeeds with a handle of 0. > If 0 is not possible then there are a few other clean-ups that we > could do at a later time. Ah, I remember now, we handle ERROR_NO_TOKEN so this means that hToken can be 0. So this means that the CloseHandle does need to check for 0 in the finally block. -Alan. From Alan.Bateman at oracle.com Mon Mar 4 12:07:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 20:07:26 +0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <51349228.9080807@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> <513469F8.4060606@oracle.com> <51348AD5.8080301@oracle.com> <51349228.9080807@oracle.com> Message-ID: <5134FEFE.90208@oracle.com> On 04/03/2013 12:23, Alexey Utkin wrote: > : >>>> > > We can have the situation with: > 1) OpenThreadToken return 0 without exception - that is ok for thread > without impersonation. > 2) processTokenWithDuplicateAccess is 0 for some reason (weak precess > privileges) > For that case we have no access to process token without exception > (hToken :=: 0). >>>> boolean hasRight = false; >>>> if (hToken != 0L) { > So, in upper line we need to check token for non-empty value. > ! Do you concern about the [false] return value for that case? >>>> try { >>>> hasRight = AccessCheck(hToken, securityInfo, >>>> accessMask, >>>> genericRead, genericWrite, genericExecute, >>>> genericAll); > Here is the actual work, that can make an exception (for example it > happens for invalid SID) >>>> } finally { >>>> CloseHandle(hToken); > If token was open it have to be closed without excuses. >>>> } >>>> } >>>> return hasRight; >>>> } >>> implementation approach? >> Can the handle to the token (hToken) be 0? In my comment I was >> suggesting: >> >> long hToken = OpenThreadToken(...); >> try { >> ... >> } finally { >> CloseHandle(hToken); >> } This mail is hard to read but I think the implementation is good. -Alan. From Alan.Bateman at oracle.com Thu Mar 7 09:40:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Mar 2013 17:40:50 +0000 Subject: A race problem about select in a small time window In-Reply-To: References: Message-ID: <5138D122.9000202@oracle.com> Sean - just a brief mail to say that I agree that there is an issue here (your changes to the impl. to reliably duplicate it are very useful). I need to study it a bit more before commenting on the proposed fix because it's a complicated scenario and also isOpen can return true at any time (due to async close). I will get back to you soon on this. -Alan On 17/12/2012 08:56, Sean Chou wrote: > Hello , > > This is the detail problem, there is a small time window in which a 3 > threads race makes select() always return 0 without blocking. > > I wrote a > testcase(http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ > ) which > needs to modify the lib code to reproduce, because the time windows is > small. > > The reproduce scenario is described in follow, use Tx for thread x: > > 1. T1 (the user code) is selecting a channel(suppose C), it just > returns from native select function, and niolib select method is > checking if the returned channel is interested in the event, then 2 > happens; > 2. T2 is closing channel C, it just set the open variable to false but > not yet closed the channel actually, and then 3 happens; > 3. T3 set the interedOps of the channel to 0. // 0 means the channel > is not interested in anything, the channel will be put into cancel > list normally. > > In this senario, T1 returns from select, and return 0 which means no > channel is selected(because the channel C returned from native > invocation has nothing insterested in, it is not returned to > application). Then T1 goes to invoke select again(usually in a loop, > this is how select is designed to be used). In normal case, select > method checks if any channels those should be cancelled and remove > them from the set to be selected. Then, goes to native select function. > > The problem is: select method first checks if the channel is closed, > if it is closed, select method doesn't put it into cancel list. > > In above senario, channel C is in close state, but not closed indeed, > and setInteredOps to 0(which means cancel). So select method doesn't > put C into cancel list(due to the problem) which means the native > select set still contains channel C . So the native select always > return C and nio select always return 0. Until the channel is finally > closed. > > > The testcase: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ > > > A working fix: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev_fix/ > > > > Please have a look. > > From Alan.Bateman at oracle.com Sun Mar 10 14:16:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Mar 2013 21:16:18 +0000 Subject: A race problem about select in a small time window In-Reply-To: <5138D122.9000202@oracle.com> References: <5138D122.9000202@oracle.com> Message-ID: <513CF822.8020103@oracle.com> On 07/03/2013 17:40, Alan Bateman wrote: > > Sean - just a brief mail to say that I agree that there is an issue > here (your changes to the impl. to reliably duplicate it are very > useful). I need to study it a bit more before commenting on the > proposed fix because it's a complicated scenario and also isOpen can > return true at any time (due to async close). I will get back to you > soon on this. > > -Alan I've created 8009751 to track this issue and I've put a preliminary fix here: http://cr.openjdk.java.net/~alanb/8009751/webrev/ The changes essentially mean that the Selector will now maintain an accurate view of the registrations so that the bulk update (at select time) does not need to be concerned with the channel state. For interestOps then it keeps it very simple as it just "queues" the update. The release is also simple as it do longer need to iterate over the pending updates. So far I've only done limited testing but all tests that I've tried so far pass. I don't know the background to your test case/patch but it would be great if you could test the patch with the application or test that you originally ran into this issue with. I think for now we can use 8009751 for this issue. As part this patch I've also changed a lot of other code (impact the other Selectors) but I'll this back for now so as now (the clean-up can be done in a later bug). -Alan. From zhouyx at linux.vnet.ibm.com Tue Mar 12 02:58:06 2013 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Tue, 12 Mar 2013 17:58:06 +0800 Subject: A race problem about select in a small time window In-Reply-To: <513CF822.8020103@oracle.com> References: <5138D122.9000202@oracle.com> <513CF822.8020103@oracle.com> Message-ID: The code looks fine, I tried with the test case in first mail and it passed. I'll try to run more testcases which need one or two days. It's a sudden you removed the Updator layer. On Mon, Mar 11, 2013 at 5:16 AM, Alan Bateman wrote: > On 07/03/2013 17:40, Alan Bateman wrote: > >> >> Sean - just a brief mail to say that I agree that there is an issue here >> (your changes to the impl. to reliably duplicate it are very useful). I >> need to study it a bit more before commenting on the proposed fix because >> it's a complicated scenario and also isOpen can return true at any time >> (due to async close). I will get back to you soon on this. >> >> -Alan >> > I've created 8009751 to track this issue and I've put a preliminary fix > here: > > http://cr.openjdk.java.net/~**alanb/8009751/webrev/ > > The changes essentially mean that the Selector will now maintain an > accurate view of the registrations so that the bulk update (at select time) > does not need to be concerned with the channel state. For interestOps then > it keeps it very simple as it just "queues" the update. The release is also > simple as it do longer need to iterate over the pending updates. > > So far I've only done limited testing but all tests that I've tried so far > pass. I don't know the background to your test case/patch but it would be > great if you could test the patch with the application or test that you > originally ran into this issue with. > > I think for now we can use 8009751 for this issue. As part this patch I've > also changed a lot of other code (impact the other Selectors) but I'll this > back for now so as now (the clean-up can be done in a later bug). > > -Alan. > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130312/ad7086ef/attachment.html From Alan.Bateman at oracle.com Tue Mar 12 05:42:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 12:42:47 +0000 Subject: A race problem about select in a small time window In-Reply-To: References: <5138D122.9000202@oracle.com> <513CF822.8020103@oracle.com> Message-ID: <513F22C7.1060005@oracle.com> On 12/03/2013 09:58, Sean Chou wrote: > The code looks fine, I tried with the test case in first mail and it > passed. > I'll try to run more testcases which need one or two days. > It's a sudden you removed the Updator layer. Thanks, in the mean-time we can do the review here. As regards removing Updator then this is part of the problem as it's too fragile to map to opcodes when queuing the change. Also it doesn't take account of the possibility of that interestOps might queue a change at just around the time that the channel is being removed. The new implementation also avoids needing to create an Updator for each change to the interest ops. -Alan From chris.hegarty at oracle.com Tue Mar 12 08:00:45 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Mar 2013 15:00:45 +0000 Subject: A race problem about select in a small time window In-Reply-To: <513CF822.8020103@oracle.com> References: <5138D122.9000202@oracle.com> <513CF822.8020103@oracle.com> Message-ID: <513F431D.8080403@oracle.com> On 03/10/2013 09:16 PM, Alan Bateman wrote: > .... > http://cr.openjdk.java.net/~alanb/8009751/webrev/ > > The changes essentially mean that the Selector will now maintain an > accurate view of the registrations so that the bulk update (at select > time) does not need to be concerned with the channel state. For > interestOps then it keeps it very simple as it just "queues" the update. > The release is also simple as it do longer need to iterate over the > pending updates. Similar to DevPollArrayWrapper, right? > So far I've only done limited testing but all tests that I've tried so > far pass. I don't know the background to your test case/patch but it > would be great if you could test the patch with the application or test > that you originally ran into this issue with. > > I think for now we can use 8009751 for this issue. As part this patch > I've also changed a lot of other code (impact the other Selectors) but > I'll this back for now so as now (the clean-up can be done in a later bug). Thanks for holding back on the cleanup, and separating it into another bug. This area is very tricky to review. Anyway, the changes look good to me. -Chris > > -Alan. From Alan.Bateman at oracle.com Tue Mar 12 08:14:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 15:14:16 +0000 Subject: A race problem about select in a small time window In-Reply-To: <513F431D.8080403@oracle.com> References: <5138D122.9000202@oracle.com> <513CF822.8020103@oracle.com> <513F431D.8080403@oracle.com> Message-ID: <513F4648.5070502@oracle.com> On 12/03/2013 15:00, Chris Hegarty wrote: > : > > > Similar to DevPollArrayWrapper, right? Similar, but there are a few subtle differences. > > Anyway, the changes look good to me. Thanks. -Alan From zhouyx at linux.vnet.ibm.com Wed Mar 13 20:17:24 2013 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Thu, 14 Mar 2013 11:17:24 +0800 Subject: A race problem about select in a small time window In-Reply-To: <513F22C7.1060005@oracle.com> References: <5138D122.9000202@oracle.com> <513CF822.8020103@oracle.com> <513F22C7.1060005@oracle.com> Message-ID: I didn't find failures in my test suite, so it's ok to go! On Tue, Mar 12, 2013 at 8:42 PM, Alan Bateman wrote: > On 12/03/2013 09:58, Sean Chou wrote: > >> The code looks fine, I tried with the test case in first mail and it >> passed. >> I'll try to run more testcases which need one or two days. >> It's a sudden you removed the Updator layer. >> > Thanks, in the mean-time we can do the review here. > > As regards removing Updator then this is part of the problem as it's too > fragile to map to opcodes when queuing the change. Also it doesn't take > account of the possibility of that interestOps might queue a change at just > around the time that the channel is being removed. The new implementation > also avoids needing to create an Updator for each change to the interest > ops. > > -Alan > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130314/c8b6df60/attachment.html From yiming.wang at oracle.com Wed Mar 13 21:18:18 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 14 Mar 2013 12:18:18 +0800 Subject: [PATCH] Review request for 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1) Message-ID: <51414F8A.4000107@oracle.com> Hi, Please help to review the fix for bug 7183800 . those tests failed on Ubuntu 12.04. http://cr.openjdk.java.net/~ewang/7183800/webrev.01/ Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130314/8ea29e98/attachment.html From Alan.Bateman at oracle.com Wed Mar 13 23:49:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 06:49:53 +0000 Subject: A race problem about select in a small time window In-Reply-To: References: <5138D122.9000202@oracle.com> <513CF822.8020103@oracle.com> <513F22C7.1060005@oracle.com> Message-ID: <51417311.8000805@oracle.com> On 14/03/2013 03:17, Sean Chou wrote: > I didn't find failures in my test suite, so it's ok to go! > Thanks, this is pushed now: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e33cbbe21419 -Alan. From Alan.Bateman at oracle.com Wed Mar 13 23:50:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 06:50:55 +0000 Subject: [PATCH] Review request for 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1) In-Reply-To: <51414F8A.4000107@oracle.com> References: <51414F8A.4000107@oracle.com> Message-ID: <5141734F.8090605@oracle.com> On 14/03/2013 04:18, Eric Wang wrote: > Hi, > > Please help to review the fix for bug 7183800 > . those tests failed > on Ubuntu 12.04. > > http://cr.openjdk.java.net/~ewang/7183800/webrev.01/ > > Thanks, > Eric This looks good to me, I will push this for you today to jdk8/tl. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130314/043b00fe/attachment.html From chris.hegarty at oracle.com Thu Mar 14 02:42:28 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Mar 2013 09:42:28 +0000 Subject: [PATCH] Review request for 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1) In-Reply-To: <5141734F.8090605@oracle.com> References: <51414F8A.4000107@oracle.com> <5141734F.8090605@oracle.com> Message-ID: <51419B84.4030602@oracle.com> Eric, Alan, This one is confusing me some what. I see the problem, but don't understand why when sending to 127.0.1.1, the from address is 127.0.0.1. Is this behavior specific to Linux, or simply that Linux (12.04) just started to have this configuration as default. I guess this issue could have been resolved by explicitly binding the channels to InetAddress.getLocalAddress either. -Chris. On 03/14/2013 06:50 AM, Alan Bateman wrote: > On 14/03/2013 04:18, Eric Wang wrote: >> Hi, >> >> Please help to review the fix for bug 7183800 >> . those tests failed >> on Ubuntu 12.04. >> >> http://cr.openjdk.java.net/~ewang/7183800/webrev.01/ >> >> Thanks, >> Eric > This looks good to me, I will push this for you today to jdk8/tl. > > -Alan. From Alan.Bateman at oracle.com Thu Mar 14 04:03:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 11:03:17 +0000 Subject: [PATCH] Review request for 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1) In-Reply-To: <51419B84.4030602@oracle.com> References: <51414F8A.4000107@oracle.com> <5141734F.8090605@oracle.com> <51419B84.4030602@oracle.com> Message-ID: <5141AE75.3010309@oracle.com> On 14/03/2013 09:42, Chris Hegarty wrote: > Eric, Alan, > > This one is confusing me some what. I see the problem, but don't > understand why when sending to 127.0.1.1, the from address is > 127.0.0.1. Is this behavior specific to Linux, or simply that Linux > (12.04) just started to have this configuration as default. > > I guess this issue could have been resolved by explicitly binding the > channels to InetAddress.getLocalAddress either. Eric's patch is a workaround for the out-of-the-box configuration. I think Ubuntu have been using 127.0.1.1 for some time. An alternative would be to bind the listener to a specific address but that changes the test subtly for all environments. -Alan From chris.hegarty at oracle.com Thu Mar 14 04:14:45 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Mar 2013 11:14:45 +0000 Subject: [PATCH] Review request for 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1) In-Reply-To: <5141AE75.3010309@oracle.com> References: <51414F8A.4000107@oracle.com> <5141734F.8090605@oracle.com> <51419B84.4030602@oracle.com> <5141AE75.3010309@oracle.com> Message-ID: <5141B125.3020701@oracle.com> On 03/14/2013 11:03 AM, Alan Bateman wrote: > On 14/03/2013 09:42, Chris Hegarty wrote: >> Eric, Alan, >> >> This one is confusing me some what. I see the problem, but don't >> understand why when sending to 127.0.1.1, the from address is >> 127.0.0.1. Is this behavior specific to Linux, or simply that Linux >> (12.04) just started to have this configuration as default. >> >> I guess this issue could have been resolved by explicitly binding the >> channels to InetAddress.getLocalAddress either. > Eric's patch is a workaround for the out-of-the-box configuration. I > think Ubuntu have been using 127.0.1.1 for some time. An alternative > would be to bind the listener to a specific address but that changes the > test subtly for all environments. Thanks for the clarification, that is what I thought. The changes look fine to me too. -Chris. > > -Alan From alexey.utkin at oracle.com Fri Mar 1 03:49:11 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 01 Mar 2013 11:49:11 -0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <512F7A9C.4030905@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> Message-ID: <513094F3.4000701@oracle.com> On 28.02.2013 19:41, Alan Bateman wrote: > On 28/02/2013 15:17, Alexey Utkin wrote: >> That is not single, but 4 additional parameters ( FILE_GENERIC_READ, >> FILE_GENERIC_WRITE, FILE_GENERIC_EXECUTE, FILE_ALL_ACCESS) - that are >> relatively complicate masks. That parameters have to be changed >> consistently to avoid the problem (there is the analogy with >> orthogonal basis in geometry If you understand what I mean). Now we >> use the [AccessCheckForFile] just in [nio] package. We can extend the >> implementation any time we need it. > Okay, I can live with this but would be nice to get it to AccessCheck > at most point. I did. >>> checkFileAccess ignores the exception from AccessCheck whereas I >>> should it should be translated to an IOException. >> That is by design. Any problem with the [checkFileAccess] need to be >> converted to the [false] return value. At the end point - in the >> [WindowsFileSystemProvider.checkAccess] function - the [false] return >> value would be converted to the [AccessDeniedException] exception - >> that is desired code flow. > My point is that AccessCheck can fail for other reasons too and it > would be good to get these reason into the exception so that it is not > lost. It might have to AccessDeniedException if there aren't specific > errors documented but at least the reason will be in the exception > message to help someone figure it the issue. So I think it would be > better to translate the exception rather than returning a boolean. Done. >>> >>> Otherwise I think this is good. You don't have a test case but I >>> can't think how this could be tested anyway as we already have tests >>> for checkAccess and isWritable. >> I have the test. It is attached to the bug as Netbeans project, but >> it need manual security setup in security tab of the [demofile.txt] >> file (as shown in attached screenshot). By changing the "Write" check >> box on the [demofile.txt] file security dialog, test result have >> varying accordingly. >> Seems the web bug-db interface is not synchronized yet. > Thanks, I guessed that an automated test would not be possible. That is possible, but includes pre-requirements for installed MS tools. That is not a good idea. New version of the fix was prepared. Bug description: http://bugs.sun.com/view_bug.do?bug_id=7190897 https://jbs.oracle.com/bugs/browse/JDK-7190897 The suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7190897/webrev.01/ Regards, -uta From alexey.utkin at oracle.com Mon Mar 4 01:34:59 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 04 Mar 2013 09:34:59 -0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <5130C2F2.8070604@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> Message-ID: <513469F8.4060606@oracle.com> Alan, Do you agree with > /** > * Check the access right against the securityInfo in the current > thread. > */ > static boolean checkAccessMask(long securityInfo, int accessMask, > int genericRead, int genericWrite, int genericExecute, int > genericAll) > throws WindowsException > { > int privilegies = TOKEN_QUERY; > long hToken = OpenThreadToken(GetCurrentThread(), privilegies, > false); > if (hToken == 0L && processTokenWithDuplicateAccess != 0L) > hToken = DuplicateTokenEx(processTokenWithDuplicateAccess, > privilegies); > > boolean hasRight = false; > if (hToken != 0L) { > try { > hasRight = AccessCheck(hToken, securityInfo, accessMask, > genericRead, genericWrite, genericExecute, > genericAll); > } finally { > CloseHandle(hToken); > } > } > return hasRight; > } implementation approach? Regards, -uta On 01.03.2013 19:02, Alan Bateman wrote: > A minor point is that in checkAccessMask then you could call > OpenThreadToken before the try/finally. That way you wouldn't need to > check hToken. Otherwise I think this is good to go and it's nice to > finally fix this issue. > > -Alan From alexey.utkin at oracle.com Mon Mar 4 04:26:27 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 04 Mar 2013 12:26:27 -0000 Subject: Request for review: 7190897 (fs) Files.isWritable method returns false when the path is writable (win). - ver. 1 In-Reply-To: <51348AD5.8080301@oracle.com> References: <512F4574.5090909@oracle.com> <512F6A4A.3080300@oracle.com> <512F7500.8010106@oracle.com> <512F7A9C.4030905@oracle.com> <513094F3.4000701@oracle.com> <5130C2F2.8070604@oracle.com> <513469F8.4060606@oracle.com> <51348AD5.8080301@oracle.com> Message-ID: <51349228.9080807@oracle.com> On 04.03.2013 15:51, Alan Bateman wrote: > On 04/03/2013 09:31, Alexey Utkin wrote: >> Alan, >> Do you agree with >>> /** >>> * Check the access right against the securityInfo in the >>> current thread. >>> */ >>> static boolean checkAccessMask(long securityInfo, int accessMask, >>> int genericRead, int genericWrite, int genericExecute, int >>> genericAll) >>> throws WindowsException >>> { >>> int privilegies = TOKEN_QUERY; >>> long hToken = OpenThreadToken(GetCurrentThread(), >>> privilegies, false); >>> if (hToken == 0L && processTokenWithDuplicateAccess != 0L) >>> hToken = DuplicateTokenEx(processTokenWithDuplicateAccess, >>> privilegies); >>> We can have the situation with: 1) OpenThreadToken return 0 without exception - that is ok for thread without impersonation. 2) processTokenWithDuplicateAccess is 0 for some reason (weak precess privileges) For that case we have no access to process token without exception (hToken :=: 0). >>> boolean hasRight = false; >>> if (hToken != 0L) { So, in upper line we need to check token for non-empty value. ! Do you concern about the [false] return value for that case? >>> try { >>> hasRight = AccessCheck(hToken, securityInfo, >>> accessMask, >>> genericRead, genericWrite, genericExecute, >>> genericAll); Here is the actual work, that can make an exception (for example it happens for invalid SID) >>> } finally { >>> CloseHandle(hToken); If token was open it have to be closed without excuses. >>> } >>> } >>> return hasRight; >>> } >> implementation approach? > Can the handle to the token (hToken) be 0? In my comment I was > suggesting: > > long hToken = OpenThreadToken(...); > try { > ... > } finally { > CloseHandle(hToken); > } > but that doesn't work if OpenThreadToken succeeds with a handle of 0. > If 0 is not possible then there are a few other clean-ups that we > could do at a later time. >> Ah, I remember now, we handle ERROR_NO_TOKEN so this means that >> hToken can be 0. So this means that the CloseHandle does need to >> check for 0 in the finally block. >> >> -Alan. > > -Alan >