From 7dc15cba4302d6432c389cd9005a9f1afadf81dd Mon Sep 17 00:00:00 2001 From: corinna Date: Tue, 2 Dec 2008 17:07:40 +0000 Subject: [PATCH] * ntsec.sgml: Finishing up changes for 1.7. --- winsup/doc/ChangeLog | 4 + winsup/doc/ntsec.sgml | 608 ++++++++++++++++++++++++++++++++++---------------- 2 files changed, 422 insertions(+), 190 deletions(-) diff --git a/winsup/doc/ChangeLog b/winsup/doc/ChangeLog index 1e29b59c63..9f57e4e431 100644 --- a/winsup/doc/ChangeLog +++ b/winsup/doc/ChangeLog @@ -1,3 +1,7 @@ +2008-12-02 Corinna Vinschen + + * ntsec.sgml: Finishing up changes for 1.7. + 2008-12-01 Corinna Vinschen * ntsec.sgml: Further changes for 1.7. Switch from "NT" to "Windows". diff --git a/winsup/doc/ntsec.sgml b/winsup/doc/ntsec.sgml index 3d568e1f59..349170fb60 100644 --- a/winsup/doc/ntsec.sgml +++ b/winsup/doc/ntsec.sgml @@ -6,7 +6,7 @@ the authentication model is used to allow to switch the user context in a POSIX-like fashion. The setting of POSIX like file and directory permissions is -controlled by the mount option +controlled by the mount option (no)acl which is set to acl by default. @@ -67,9 +67,9 @@ The next two numbers are the authority which shows the initiated what kind of SID this is. There are a couple of builtin accounts and accounts with very special meaning. However, computer and domain SIDs always start with "S-1-5-21". The next three numbers, all 32 bit values, -are the unique 96 bit identifier of the comupter system. This is +are the unique 96 bit identifier of the computer system. This is hopefully unique all over the world, but in practice it's sufficient if -the comuter SIDs are unique within a single Windows network. +the computer SIDs are unique within a single Windows network. As you can see in the above example, SIDs of users (and groups) are identical to the computer SID, except for an additional part, the @@ -97,7 +97,7 @@ controller and you would like to create a domain account "johndoe": S-1-5-21-186985262-1144665072-740312968-1207 -Ok, so you now have two accounts called johndoe, one account +So you now have two accounts called johndoe, one account created on the machine "foo", one created in the domain "bar.local". Both have different SIDs and not even the RID is the same. How do the systems know it's the same account? After all, the name is @@ -110,7 +110,7 @@ Different SID, different account. Full stop. The last part of the SID, the so called "Relative IDentifier" (RID), is by default used as UID and/or GID under Cygwin when you create the /etc/passwd and /etc/group -files using the mkpasswd and mkgroup +files using the mkpasswd and mkgroup tools. Domain account UIDs and GIDs are offset by 10000 by default which might be a bit low for very big organizations. Fortunately there's an option in both tools to change the offset... @@ -121,8 +121,9 @@ for the group of "all users" or "world" or "others". The last three rwx bits in a permission value just represent the permissions for "everyone who is not the owner or is member of the owning group". Windows has a SID for these poor souls, the "Everyone" SID. Other well-known SIDs -represent more circumstances instead of actual users or groups. Here -are a few examples for well-known SIDs: +represent circumstances under which a process is running, rather than +actual users or groups. Here are a few examples for well-known +SIDs: Everyone S-1-1-0 Simply everyone... @@ -140,7 +141,7 @@ SYSTEM S-1-5-18 A special account which has all an uber-root account. -For a full list please refer to +For a full list please refer to the MSDN document Well-known SIDs. Naturally well-known SIDs are the same on each machine, so they are not unique to a machine or domain. They have the same meaning across @@ -166,8 +167,8 @@ member of these well known groups. Consider the domain group "Domain Admins". This group is by default in the "Administrators" group. Let's assume the above computer called "foo" is a member machine of the domain "bar.local". If you stick the user "BAR\johndoe" into the group "Domain -Admins", this guy will automatically be a mamber of the administrators -group on "foo", when logging in on "foo". Neat, isn't it? +Admins", this guy will automatically be a member of the administrators +group on "foo" when logging on to "foo". Neat, isn't it? Back to ACE and ACL. POSIX is able to create three different permissions, the permissions for the owner, for the group and for the @@ -194,6 +195,16 @@ data. But there's a problem with the definition of a "correct" ACL which disallows to map certain POSIX permissions cleanly. See . +POSIX is able to create only three different permissions? Not quite. +Newer operating systems and file systems on POSIX systems also provide +access control lists. Two different APIs exist for accessing these +ACLs, the Solaris API and the POSIX API. Cygwin implements the Solaris +API to access Windows ACLs in a Unixy way. At the time of writing this +document, the Cygwin implementation of the Solaris API isn't quite up +to speed. For instance, it doesn't handle access denied ACEs gracefully. +So, use with care. Online man pages for the Solaris ACL API can be +found on http://docs.sun.com. + File permissions @@ -206,7 +217,7 @@ SIDs, and a DACL which contains ACEs for the owner, the group and for To use Windows security correctly, Cygwin depends on the files /etc/passwd and /etc/group. -These files define the traslation between the Cygwin uid/gid and the +These files define the translation between the Cygwin uid/gid and the Windows SID. The SID is stored in the pw_gecos field in /etc/passwd, and in the gr_passwd field in /etc/group. Since the pw_gecos field can contain @@ -218,10 +229,9 @@ usually do this for you. Another interesting entry in the pw_gecos field (which is also usually created by running mkpasswd) is the Windows user -name entry. It takes the form "U-domain\username" and is typically used -by services to authenticate a user. Logging in through ssh -or telnet are two typical scenarios. - +name entry. It takes the form "U-domain\username" and is sometimes used +by services to authenticate a user. Logging in through +telnet is a common scenario. A typical snippet from /etc/passwd: @@ -237,12 +247,13 @@ corinna:unused:11001:11125:U-BAR\corinna,S-1-5-21-2913048732-1697188782-34488111 The SYSTEM entry is usually needed by services. The Administrators entry (Huh? A group in /etc/passwd?) is only here to allow -ls to print some file ownerships correctly. Windows -doesn't care if the owner of a file is a user or a group. In older -versions of Windows NT the default ownership for files created by an -administrator account was set to the group Administrators instead of to -the creating user account. This has changed, but for those older -systems it's convenient to have the Administrators group in +ls and similar commands to print some file ownerships +correctly. Windows doesn't care if the owner of a file is a user or a +group. In older versions of Windows NT the default ownership for files +created by an administrator account was set to the group Administrators +instead of to the creating user account. This has changed, but you can +still switch to this setting on newer systems. So it's convenient to +have the Administrators group in /etc/passwd. The really interesting entries are the next two. The Administrator @@ -251,7 +262,7 @@ account in the domain BAR. The information given in the pw_gecos field are all we need to exactly identify an account, and to have a two way translation, from Windows account name/SID to Cygwin account name uid and vice versa. Having this complete information allows us to choose a Cygwin -name and uid which doesn't have to match the Windows account at all. As +user name and uid which doesn't have to match the Windows account at all. As long as the pw_gecos information is available, we're on the safe side: @@ -292,10 +303,11 @@ which in turn is member of the well-known group "Users". So, if it's more feasible in your environment that the user's primary group is "Users", just set the user's primary group in /etc/passwd to the Cygwin uid of "Users" (see in /etc/group, -default 545). +default 545) and let the user create files with a default group ownership +of "Users". However, here's a WARNING: If you want to do similar changes to -your files, please do that only if you're feeling comfortably with the +your files, please do that only if you're feeling comfortable with the concepts. Otherwise don't be surprised if some stuff doesn't work anymore. If you screwed up things, revert to /etc/passwd and /etc/group files created by mkpasswd @@ -306,6 +318,78 @@ strangely. +Special values of user and group ids + +If the current user is not present in +/etc/passwd, that user's uid is set to a +special value of 400. The user name for the current user will always be +shown correctly. If another user (or a Windows group, treated as a +user) is not present in /etc/passwd, the uid of +that user will have a special value of -1 (which would be shown by +ls as 65535). The user name shown in this case will +be '????????'. + +If the current user is not present in +/etc/passwd, that user's login gid is set to a +special value of 401. The gid 401 is shown as 'mkpasswd', +indicating the command that should be run to alleviate the +situation. + +If another user is not present in +/etc/passwd, that user's login gid is set to a +special value of -1. If the user is present in +/etc/passwd, but that user's group is not in +/etc/group and is not the login group of that user, +the gid is set to a special value of -1. The name of this group +(id -1) will be shown as '????????'. + +If the current user is present in +/etc/passwd, but that user's login group is not +present in /etc/group, the group name will be shown +as 'mkgroup', again indicating the appropriate command. + +A special case is if the current user's primary group SID is noted +in the user's /etc/passwd entry using another group +id than the group entry of the same group SID in +/etc/group. This should be noted and corrected. +The group name printed in this case is +'passwd/group_GID_clash(PPP/GGG)', with PPP being the gid as noted +in /etc/passwd and GGG the gid as noted in +/etc/group. + +To summarize: + + +If the current user doesn't show up in +/etc/passwd, it's group will +be named 'mkpasswd'. + +Otherwise, if the login group of the current user isn't +in /etc/group, it will be named 'mkgroup'. + + +Otherwise a group not in /etc/group +will be shown as '????????' and a user not in +/etc/passwd will be shown as "????????". + + +If different group ids are used for a group with the same +SID, the group name is shown as 'passwd/group_GID_clash(PPP/GGG)' with +PPP and GGG being the different group ids. + + + + +Note that, since the special user and group names are just indicators, +nothing prevents you from actually having a user named `mkpasswd' in +/etc/passwd (or a group named `mkgroup' in +/etc/group). If you do that, however, be aware of +the possible confusion. + + + + + The POSIX permission mapping leak As promised earlier, here's the problem when trying to map the @@ -320,16 +404,16 @@ documentation explains in short the following: ACEs of the user as well as all groups the user is member of. The permissions given in these user and groups access allowed ACEs are accumulated and the resulting set is the set of permissions of that -user. +user given for that object. The order of ACEs is important. The system reads them in sequence until either any single requested permission is denied or all requested permissions are granted. Reading stops when this condition is met. Later ACEs are not taken into account. -All access denied ACEs _should_ precede any access -allowed ACE. ACLs following this rule are called "canonical" - +All access denied ACEs should precede any access allowed ACE. ACLs +following this rule are called "canonical" Note that the last rule is a preference or a definition of @@ -343,7 +427,7 @@ the Windows NT4 explorer is completely unable to deal with access denied ACEs while the Windows 2000 and later properties dialog rearranges the order of the ACEs to canonical order before you can read them. Thank God, the sort order remains unchanged if one presses the Cancel button. But don't -even _think_ of pressing OK... +even think of pressing OK... Canonical ACLs are unable to reflect each possible combination of POSIX permissions. Example: @@ -405,43 +489,49 @@ aren't able (or willing) to deal with that order. -Switching the user context -POSIX applications which have to switch the user context are using -the setuid and seteuid calls. +Switching the user context -Windows doesn't support the concept of these calls in a simple +POSIX applications which have to switch the user context are using +the setuid and seteuid calls. +Windows doesn't support the concept of these calls in a simple fashion and switching the user context in Windows is generally a tricky process with lots of "behind the scenes" magic involved. - +Windows uses so-called `access tokens' to identify a user and its +permissions. Usually the access token is created at logon time and then +it's attached to the starting process. Every new process within a session +inherits the access token from its parent process. Every thread can +get its own access token, which allows to define threads with restricted +permissions. To switch the user context the process has to request such +an access token for the new user. -Windows uses so-called `access tokens' to identify a user and it's -permissions. To switch the user context the application has to request -such an `access token'. This is typically done by calling the Win32 API -function LogonUser. The access token is returned and -either used in ImpersonateLoggedOnUser to change user -context of the current process or in CreateProcessAsUser -to change user context of a spawned child process. An important restriction -is that the application using LogonUser must have special -permissions: - - -"Act as part of the operating system" -"Replace process level token" -"Increase quotas" - + -Note that administrators do not have all these user rights set -by default. +Switching the user context with password authentication -Two new Cygwin calls are introduced to support porting -setuid applications with a minimum of effort. You only -give Cygwin the right access token and then you can call -seteuid or setuid as usual in POSIX -applications. The call to sexec is not needed -anymore. Porting a setuid application is illustrated by -a short example: +To switch the user context the process has to request such an access +token for the new user. This is typically done by calling the Win32 API +function LogonUser. The access token is returned and +either used in ImpersonateLoggedOnUser to change the +user context of the current thread, or in +CreateProcessAsUser to change the user context of a +spawned child process. Later versions of Windows define new functions +in this context and there are also functions to manipulate existing +access tokens (usually only to restrict them). Windows Vista also adds +subtokens which are attached to other access tokens which plays an +important role in the UAC (User Access Control) facility of Vista and +later. However, none of these extensions are really important for +this documentation. + +Back to this logon with password, how can this be used to +implement set(e)uid? Well, it requires to patch the +calling application. Two Cygwin functions have been introduced to support +porting setuid applications which only require login +with passwords. You only give Cygwin the right access token and then +you can call seteuid or setuid as +usual in POSIX applications. Porting such a setuid +application is illustrated by a short example: #ifdef __CYGWIN__ /* Patch the typical password test. */ - if (is_winnt) - { - HANDLE token; - - /* Try to get the access token from NT. */ - token = cygwin_logon_user (user_pwd_entry, cleartext_password); - if (token == INVALID_HANDLE_VALUE) - error_exit; - /* Inform Cygwin about the new impersonation token. - Cygwin is able now, to switch to that user context by - setuid or seteuid calls. */ - cygwin_set_impersonation_token (token); - } - else -#endif /* CYGWIN */ - /* Use standard method for W9X as well. */ + { + HANDLE token; + + /* Try to get the access token from Windows. */ + token = cygwin_logon_user (user_pwd_entry, cleartext_password); + if (token == INVALID_HANDLE_VALUE) + error_exit; + /* Inform Cygwin about the new impersonation token. + Cygwin is able now, to switch to that user context by + setuid or seteuid calls. */ + cygwin_set_impersonation_token (token); + } +#else + /* Use standard method on non-Cygwin systems. */ hashed_password = crypt (cleartext_password, salt); if (!user_pwd_entry || strcmp (hashed_password, user_pwd_entry->pw_password)) error_exit; +#endif /* CYGWIN */ [...] @@ -494,157 +583,296 @@ a short example: -The new Cygwin call to retrieve an access token is defined as follows: + - -#include <windows.h> -#include <sys/cygwin.h> +Switching the user context without password, Method 1: Create a token from scratch + +So far unfortunate for the implementation of a +set(e)uid call is the fact that the calling process +needs the password of the user it wants to switch to. Applications like +sshd wishing to switch the user context after a +successful public key authentication, or cron which +has to switch the user without any authentication are stuck here. But +there are other ways to get new user tokens. + +One way is just to create a user token from scratch. This is +accomplished by using an (officially undocumented) function on the NT +function level. The NT function level is closer to the actual kernel +than the Win32 level. Actually the Win32 functions are implemented +using the NT functions. The function we're interested in is +NtCreateToken. This function allows to specify +user, groups, permissions and almost everything you need to create +a user token, without the need to specify the user password. The +only restriction for using this function is that the calling process +needs the "Create a token object" user right, which only the +SYSTEM user account has by default, and which is considered the most +dangerous right a user can have on Windows systems. + +That sounds good. We just start the servers which have to switch +the user context (sshd, inetd, +cron, ...) as Windows services under the SYSTEM +(or LocalSystem in the GUI) account and everything just works. +Unfortunately that's too simple. Using NtCreateToken +has a few drawbacks. + +First of all, beginning with Windows Server 2003, +the permission "Create a token object" gets explicitely removed from +the SYSTEM user's access token, when starting services under that +account. That requires to create a new account with this specific +permission just to run this kind of services. But that's a minor +problem. + +A more important problem is that using NtCreateToken +is not sufficient to create a new logon session for the new user. What +does that mean? Every logon usually creates also a new logon session. +A logon session has a couple of attributes which are unique to the +session. One of these attributes is the fact, that Windows functions +identify the user domain and user name not by the SID of the access +token owner, but only by the logon session the process is running under. + +What that means is this. Consider a service started under the +SYSTEM account (up to Windows XP) switches the user context to +DOMAIN\my_user using a token created directly by calling the +NtCreateToken function. A process running under this +new access token might want to know under which user account it's +running. The corresponding SID is returned correctly, for instance +S-1-5-21-1234-5678-9012-77777. However, if the same process asks the OS +for the user name of this SID something wierd happens. For instance, +the LookupAccountSid function will not return +"DOMAIN\my_user", but "NT AUTHORITY\SYSTEM" as the user name. + +You might ask "So what?" After all, this only looks bad, but functionality and permission-wise +everything should be ok. And Cygwin knows about this shortcoming so it +will return the correct Cygwin username when asked. Unfortunately this +is more complicated. Some native, non-Cygwin Windows applications will +misbehave badly in this situation. A well-known example are certain versions +of Visual-C++. + +Last but not least, you don't have the usual comfortable access +to network shares. The reason is that the token has been created +without knowing the password. The password are your credentials +necessary for network access. Thus, if you logon with a password, the +password is stored hidden as "token credentials" within the access token +and used as default logon to access network resources. Since these +credentials are missing from the token created with +NtCreateToken, you only can access network shares +from the new user's process tree by using explicit authentication, on +the command line for instance: -HANDLE -cygwin_logon_user (struct passwd *pw, const char *cleartext_password) + +bash$ net use '\\server\share' /user:DOMAIN\my_user my_users_password -You can call that function as often as you want for different user -logons and remember the access tokens for further calls to the second function. +Note that, on some systems, you can't even define a drive letter +to access the share, and under some circumstances the drive letter you +choose collides with a drive letter already used in another session. +Therefore it's better to get used to accessing these shares using the UNC +path as in -#include <windows.h> -#include <sys/cygwin.h> - -void -cygwin_set_impersonation_token (HANDLE hToken); +bash$ grep foo //server/share/foofile - is the call to inform Cygwin about the user context to which further -calls to setuid/seteuid should switch to. -While you always need the correct access token to do a -setuid/seteuid to another user's context, -you are always able to use setuid/seteuid -to return to your own user context by giving your own uid as parameter. - -If you have remembered several access tokens from calls to -cygwin_logon_user you can switch to different user -contexts by observing the following order: - - + - cygwin_set_impersonation_token (user1_token); - seteuid (user1_uid); +Switching the user context without password, Method 2: LSA authentication package + +Caveat: The method described in this chapter only works starting +with Windows 2000. Windows NT4 users have to use one of the other +methods described in this document. + +So we're looking for another way to switch the user context without +having to provide the password. Another technique is to create an +LSA authentication package. LSA is an acronym for "Local Security Authority" +which is a protected part of the operating system which only allows changes +to become active when rebooting the system after the change. Also, as soon as +the LSA encounters serious problems (for instance, one of the protected +LSA processes died), it triggers a system reboot. LSA is the part of +the OS which cares for the user logons and which also creates logon +sessions. + +An LSA authentication package is a DLL which has to be installed +as part of the LSA. This is done by tweaking a special registry key. +Cygwin provides such an authentication package. It has to be installed +and the machine has to be rebooted to activate it. This is the job of the +shell script /usr/bin/cyglsa-config which is part of +the Cygwin package. + +After running /usr/bin/cyglsa-config and +rebooting the system, the LSA authentication package is used by Cygwin +when set(e)uid is called by an application. The +created access token using this method has its own logon session. + +This method has two advantages over the NtCreateToken +method. + +The very special and very dangerous "Create a token object" user +right is not required by a user using this method. Other privileged +user rights are still necessary, especially the "Act as part of the +operating system" right, but that's just business as usual. + +The user is correctly identified, even by delicate native applications +which choke on that using the NtCreateToken method. + +Disadvantages? Yes, sure, this is Windows. The access token +created using LSA authentication still lacks the credentials for network +access. After all, there still hasn't been any password authentication +involved. The requirement to reboot after every installation or +deinstallation of the cygwin LSA authentication DLL is just a minor +inconvenience compared to that... + +Nevertheless, this is already a lot better than what we get by +using NtCreateToken, isn't it? -[...] + - seteuid (own_uid); - cygwin_set_impersonation_token (user2_token); - seteuid (user2_uid); + -[...] +Switching the user context without password, Method 3: With password + +Ok, so we have solved almost any problem, except for the network +access problem. Not being able to access network shares without +having to specify a cleartext password on the command line or in a +script is a harsh problem for automated logons for testing purposes +and similar stuff. + +Fortunately there is a solution, but it has its own drawbacks. +But first thing first, how does it work? The title of this section +says it all. Instead of trying to logon without password, we just logon +with password. The password gets stored two-way encrypted in a hidden, +obfuscated area of the registry, the LSA private registry area. This +part of the registry contains for instance the passwords of the Windows +services which run under some non-default user account. + +So what we do is to utilize this registry area for the purpose of +set(e)uid. The Cygwin command passwd -R allows a user to specify +his/her password for storage in this registry area. When this user +tries to login using ssh with public key authentication, Cygwin's +set(e)uid examines the LSA private registry area and +searches for a Cygwin specific key which contains the password. If it +finds it, it calls LogonUser under the hood, using +this password. If that works, LogonUser returns an +access token with all credentials necessary for network access. + +For good measure, and since this way to implement +set(e)uid is not only used by Cygwin but also by +Microsoft's SFU (Services for Unix), we also look for a key stored by +SFU (using the SFU command regpwd) and use that if it's +available. + +We got it. A full access token with its own logon session, with +all network credentials. Hmm, that's heaven... + +Back on earth, what about the drawbacks? + +First, adding a password to the LSA private registry area +requires administrative access. So calling passwd -R +as a normal user will fail. Cygwin provides a workaround for +this. If cygserver is started as a service running +under the SYSTEM account (which is the default way to run +cygserver) you can use passwd -R +as normal, non-privileged user as well. Just keep in mind that this +requires to set the environment variable CYGWIN to contain the word +"server" before running passwd -R, if it's not +already set anyway. See . +Example: - seteuid (own_uid); - cygwin_set_impersonation_token (user1_token); - seteuid (user1_uid); + +bash$ echo $CYGWIN +tty +bash$ export CYGWIN="tty server" +bash$ passwd -R + -etc. +Second, as aforementioned, the password is two-way encrypted in a +hidden, obfuscated registry area. Only SYSTEM has access to this area +for listing purposes, so, even as an administrator, you can't examine +this area with regedit. Right? No. Every administrator can start +regedit as SYSTEM user: + +bash$ date +Tue Dec 2 16:28:03 CET 2008 +bash$ at 16:29 /interactive regedit.exe - +Additionally, if an administrator knows under which name +the private key is stored (which is well-known since the algorithms +used to create the Cygwin and SFU keys are no secret), every administrator +can access the password of all keys stored this way in the registry. -Switching User -Context +Conclusion: If your system is used exclusively by you, and if +you're also the only administrator of your system, and if your system is +adequately locked down to prevent malicious access, you can savely use +this method. If your machine is part of a network which has +dedicated administrators, and you're not one of these administrators, +but you (think you) can trust your administrators, you can probably +savely use this method. - -Since Cygwin release 1.3.3, applications that are members of the -Administrators group and have the Create a token -object, Replace a process level token and -Increase Quota user rights can switch user -context without giving a password by just calling the usual -setuid, seteuid, -setgid and setegid functions. - - -Up to Windows XP the SYSTEM user has these privileges and can -run services such as sshd. However, startung with Windows 2003 -SYSTEM lacks the -Create a token object right, so it is necessary to -create a special user with all the necessary rights, as -well as Logon as a service, to run such services. -For security reasons this user should be denied the rights to logon -interactively or over the network. All this is done by configuration -scripts such as ssh-host-config. - - -An important restriction of this method is that a process started -without a password cannot access network shares which require -authentication. This also applies to subprocesses which switched user -context without a password. Therefore, when using -ssh or rsh without a password, it -is typically not possible to access network drives. - +In all other cases, don't use this method. You have been warned. -Special values of user and group -ids +Switching the user context, how does that all fit together? - -If the current user is not present in /etc/passwd, -that user's user id is set to a special value of 400. The user name for -the current user will always be shown correctly. If another user -(or a Windows group, treated as a user) is not present in -/etc/passwd, the user id of that user will have a -special value of -1 (which would be shown by ls as -65535). The user name shown in this case will be '????????'. - +Now we learned about four different ways to switch the user +context using the set(e)uid system call, but +how does set(e)uid really work? Which method does it +use now? - -If the current user is not present in /etc/passwd, -that user's login group id is set to a special value of 401. If another -user is not present in /etc/passwd, that user's login -group id is set to a special value of -1. If the user is present in -/etc/passwd, but that user's group is not in -/etc/group and is not the login group of that user, -the group id is set to a special value of -1. The name of this group -(id -1) will be shown as '????????'. -In releases of Cygwin before 1.3.20, the group id 401 had a group name -'None'. Since Cygwin release 1.3.20, the group id 401 is shown as -'mkpasswd', indicating the command that should be run to alleviate the -situation. - +The answer is, all four of them. So here's a brief overview +what set(e)uid does under the hood: + + +When set(e)uid is called, it tests if the +user context had been switched by an earlier call already, and if the +new user account is the privileged user account under which the process +had been started originally. If so, it just switches to the original +access token of the process it had been started with. + + + -Also, since Cygwin release 1.3.20, if the current user is present in -/etc/passwd, but that user's login group is not -present in /etc/group, the group name will be shown -as 'mkgroup', again indicating the appropriate command. - +Next, it tests if an access token has been stored by an earlier call +to cygwin_set_impersonation_token. If so, it tests +if that token matches the requested user account. If so, the stored +token is used for the user context switch. -To summarize: - + +If not, there's no predefined token which can just be used for +the user context switch, so we have to create a new token. The order +is as follows. + -If the current user doesn't show up in -/etc/passwd, it's group will -be named 'mkpasswd'. + +Check if the user has stored the logon password in the LSA +private registry area, either under a Cygwin key, or under a SFU key. +If so, use this to call LogonUser. If this +succeeds, we use the resulting token for the user context switch. + -Otherwise, if the login group of the current user isn't -in /etc/group, it will be named 'mkgroup'. + +Otherwise, check if the Cygwin-specifc LSA authentication package +has been installed and is functional. If so, use the appropriate LSA +calls to communicate with the Cygwin LSA authentication package and +use the returned token. -Otherwise a group not in /etc/group -will be shown as '????????' and a user not in -/etc/passwd will be shown as "????????". + +Last chance, try to use the NtCreateToken call +to create a token. If that works, use this token. + +If all of the above fails, our process has insufficient privileges +to switch the user context at all, so set(e)uid +fails and returns -1, setting errno to EPERM. + - -Note that, since the special user and group names are just indicators, -nothing prevents you from actually having a user named `mkpasswd' in -/etc/passwd (or a group named `mkgroup' in -/etc/group). If you do that, however, be aware of -the possible confusion. - - -- 2.11.0