Re: ACEs and ACLs
This is a somewhat belated reply to your emails concerning my troubles with ACLs. It is belated because the environment which I attempt to manage via a single administrative account looking at all mounted file systems as if they were local to whichever workstation I happen to be working from is rather large after several decades of evolution of hardware, bioses and operating systems and has taken me this much time to apply the recommended fstab setting and test against all the different source and target destinations. [My environment is actually rather minuscule as compared to what many professional sys admins accomplish daily in using Cygwin in their corporate environments with hundreds of users, but pretty large for a private, home network.] So, the primary purpose of this follow-up is to thank you for the 'noacl' advice and to confirm that I am back to having the necessary controls. Thank you. But, while it is true that I have accomplished my task, in a low priority back-drop, if you have the time, I would appreciate being pointed to any documentation or tutorials that might help me understand the conundrum with which the experience leaves me. Namely: Even with noacl specified, the result of modifying some simple text file -- either locally or remotely -- causes some perturbation in the resulting set and order of ACEs in the ACL for that file versus what is the result if I use some native, non-cygwin software to perform precisely the same modification -- again, either operating locally or remotely. This lack of real understanding on my part could be looked at from these two questions that I have: A. If noacl is _not_ the default setting for a Cygwin install, it would seem that the existing handling of ACLs must meet most of the user community's needs. For what sorts of networks and/or environments -- which must differ from mine as being comprised solely of Windows Mapped Network Drives having ntsf partitions -- does the fstab option of acl work better than noacl? or, alternately B. Are the differences that can be observed in the resulting ACL state of a simple text file being 'touched' by a native Windows executable and a similar Cygwin executable only differences in style or syntactical preference but no actual difference in the suite of permissions available to both local and remotely authenticated users? [I have been able to discern, for example, differences between explicit and inherited specifications, but there are also differences which derive, as it seems from the use of specified in what the icacls documentation page describes as "basic" as contrasted with "advanced" permissions.] Thanks for whatever you can suggest on my non-critical, low-priority request for additional information. On 2024-03-18 08:43, Corinna Vinschen via Cygwin wrote: On Mar 18 08:30, J. Terry Corbet via Cygwin wrote: Thank you for the greatly needed assistance, but the reference to which you have pointed me says that noacl will be ignored in the case of ntfs file systems. No, it doesn't say that. It says "The flag is ignored on NFS filesystems." ^^^ not NTFS All of mine are and that has not changed, neither has the default entry in fstab, which seems always to have been: none /cygdrive cygdrive binary, posix=0, user 0 0 Well, the code in question hasn't changed for years either. ¯\_(ツ)_/¯ Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
On Mar 20 12:39, Christian Franke via Cygwin wrote: > Corinna Vinschen via Cygwin wrote: > > You have to create an application with an application manifest not > > supporting your OS. > > > > For Cygwin apps, this occured when you built, say, an executable under > > Windows 8.1 before Windows 10 support was added to the Cygwin toolchain: > > the manifest linked to the Cygwin executable didn't yet contain a GUID > > entry for Windows 10 support. > > > > In this case, RtlGetVersion returns an OS version 6.3 even when running > > under the 10.0 kernel. This behaviour exists back 'til Windows Vista. > > Could not reproduce the latter on Win10. I tested with recent Win10 and > Win11 and also found a Win10 1511 (and Slackware 1.1.2, Win3.1, OS/2, ...) > in my VM image museum. > > Regardless of the exe manifest, RtlGetVersion and RtlGetNtVersionNumbers > return the correct versions: > 10.0.22621 (Win11 22H2) > 10.0.19045 (Win10 22H2) > 10.0.10586 (Win10 1511) > > Without a manifest, GetVersionEx returns: > 6.2.9200 (Win8) Please check on commit 48511f3d3847c. It was a real, existing problem at the time. I wouldn't have added the RtlGetNtVersionNumbers call just for fun. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
On Wed, Mar 20, 2024 at 5:40 AM Christian Franke wrote: Corinna Vinschen via Cygwin wrote: > > > For Cygwin apps, this occured when you built, say, an executable under > > Windows 8.1 before Windows 10 support was added to the Cygwin toolchain: > > the manifest linked to the Cygwin executable didn't yet contain a GUID > > entry for Windows 10 support. > > > > In this case, RtlGetVersion returns an OS version 6.3 even when running > > under the 10.0 kernel. This behaviour exists back 'til Windows Vista. > > Could not reproduce the latter on Win10. I tested with recent Win10 and > Win11 and also found a Win10 1511 (and Slackware 1.1.2, Win3.1, OS/2, > ...) in my VM image museum. > > Regardless of the exe manifest, RtlGetVersion and RtlGetNtVersionNumbers > return the correct versions: > 10.0.22621 (Win11 22H2) > 10.0.19045 (Win10 22H2) > 10.0.10586 (Win10 1511) > > Without a manifest, GetVersionEx returns: > 6.2.9200 (Win8) Thanks for testing. That was my recollection (RtlGetVersion is not subject to manifesting). Bill -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
Corinna Vinschen via Cygwin wrote: On Mar 19 09:18, Bill Stewart via Cygwin wrote: On Tue, Mar 19, 2024 at 9:01 AM Richard Campbell wrote: On Tue, Mar 19, 2024 at 9:04 AM Bill Stewart via Cygwin wrote: Can you please clarify the circumstances under which the RtlGetVersion function "may not return the correct values"? "Originally, using RtlGetVersion instead of GetVersionEx was supposed to fix the fact that GetVersionInfo returns the wrong kernel version if the executable has been built with an old manifest (or none at all), starting with Windows 8.1. Either this never really worked as desired and our testing was flawed, or this has been changed again with Windows 10, so that RtlGetVersion does the kernel faking twist as well. Since we're only reading the value in the first process in a process tree. the entire process tree is running with a wrong OS version information in that case. Fortunately, the (undocumented) RtlGetNtVersionNumbers function is not affected by this nonsense, so we simply override the OS version info fields with the correct values now." https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=48511f3d3847c35352d09cded56e25f0c1b22bc9 Interesting. I have not yet been able to find a scenario where the RtlGetVersion function gets "manifested" like GetVersionEx. I wrote a small Win32 console utility for displaying and testing OS information (requires Windows Vista/Server 2008 or later): https://github.com/Bill-Stewart/osinfo It uses RtlGetVersion, and this function works correctly for me in all current Windows versions (Windows 10, Server 2016, Windows 11, Server 2019, Server 2022, etc.). I'm not sure of the exact scenario that led to the "RtlGetVersion is subject to manifesting" conclusion, but I can't reproduce it. You have to create an application with an application manifest not supporting your OS. For Cygwin apps, this occured when you built, say, an executable under Windows 8.1 before Windows 10 support was added to the Cygwin toolchain: the manifest linked to the Cygwin executable didn't yet contain a GUID entry for Windows 10 support. In this case, RtlGetVersion returns an OS version 6.3 even when running under the 10.0 kernel. This behaviour exists back 'til Windows Vista. Could not reproduce the latter on Win10. I tested with recent Win10 and Win11 and also found a Win10 1511 (and Slackware 1.1.2, Win3.1, OS/2, ...) in my VM image museum. Regardless of the exe manifest, RtlGetVersion and RtlGetNtVersionNumbers return the correct versions: 10.0.22621 (Win11 22H2) 10.0.19045 (Win10 22H2) 10.0.10586 (Win10 1511) Without a manifest, GetVersionEx returns: 6.2.9200 (Win8) -- Regards, Christian -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
