On Jan 21 22:18, John Ruckstuhl via Cygwin wrote: > I am seeing a weird phenomenon, hopefully someone can illuminate and teach. > Or point me to an archived thread. > > I have some folders that Cygwin utils can readily access, > but W10 utils claim to have no access to. > It feels as if > * the Cygwin utils try to do what they are commanded to do, and it's > up to the OS to refuse if the ACLs are insufficient. > * the W10 utils are written to decline to attempt access, due to some > convention or gentlemen's agreement (built into some API?). > But wouldn't that lead Windows users to a false sense of protection, a > false sense of security?
No, this has nothing to do with security, just with a weird concept of user privileges. Here's what happens: > And (for Local Administrator Bob) no impediment to removing them, for example, > $ rm -r _MEI21282 > (success!) > > BUT Windows utils run by Bob the Administrator on the remaining dir > are blocked, like this As you know, a "root" user on a Unix system has the right to ignore file permissions. That's why root users often have "rm" aliased to "rm -i" :) Windows OTOH manages so called user privileges stored in the user's access token. One of these privileges is the right to ignore permissions while reading (SE_BACKUP_PRIVILEGE), another privilege is the right to set the ACL of a file to arbitrary permissions (SE_RESTORE_PRIVILEGE). These are the two privileges covering what a "root" user can do to files. As the names of these privileges suggest, they were originally thought of privileges you only need for backup tools. Users in the Administrators group have these privileges in their user token. Under UAC, both privileges are removed from the token. In an elevated shell, though, both privileges are present. The funny thing here is this: While both privileges are present in the token, they are disabled by default. They have to be enabled explicitely before you can exercise the privileges. Usually you do this in the same application programatically. Apart from backup tool, standard Windows tools practically *never* enable these privileges, so they fail in various circumstances. For instance, a standard "del" in the CMD shell is not able to delete a file even as administrator, if the file permissions don't allow delete access for the Administrators group. That's when you have to "take ownership" in the GUI as a last resort. In NT4 times, even that had a good chance to fail for some reason I never understood, back in the days. However, since this concept is pretty weird and not a Unix concept, the Cygwin DLL enables both privileges by default right at process startup. If the privileges are not in the user token, nothing happens. But if the privileges are present, as for an elevated process of a user in the Administrators group, then they will be enabled, and you're a "root" user in the Unix sense. And then it's "alias rm = rm -i" time again ;) HTH, 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
