On Thu, Mar 18, 2004 at 02:24:25PM -0500, Pierre A. Humblet wrote: > > Here is another hypothesis. Cygwin gets the groups from a variety of > sources during setuid(). One of them is a call to NetUserGetGroups > to get the global groups from the logon server. > Failure of that call does not call a failure of setuid, because it > happens normally while running disconnected. So the problem could be > with your logon server or your LAN. > That hypothesis seems consistent with the outputs of your original > mail. > Fortunately there is a workaround: edit /etc/group and explicitly > include the user in question in the groups that should contain him.
Looking back at your original mail, you report *** Administrator on smoke3 *** uid=10500(Administrator) gid=10513(Domain Users) groups=10512(Domain Admins),105 13(Domain Users),10519(Enterprise Admins),10520(Group Policy Creator Owners),105 18(Schema Admins),544(Administrators),545(Users) When ssh works abnormally: *** Administrator on smoke3 *** uid=10500(Administrator) gid=10513(Domain Users) groups=10513(Domain Users),545(Users) I assume you care mainly about group 544 membership. It looks like that membership derives from membership in one of the global groups 10512, 10519, 10520 and/or 10518. If you care about all of them, include the user on the appropriate lines in /etc/group on the sshd machine. An alternative if you only care about 544 is to explicitly include 10500 as a member of the Administrators group in the Windows user manager on the sshd machine. The advantage is that you won't need to reedit /etc/group each time you regenerate it. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/