X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C93238582A3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1708723014; bh=vUdPihBe+bLB9zUsiBndr25mjZimabJC3Nj3L5Q48LE=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=DD9qs4zMqZxWs52LWiPBKUvm7yuBOrT24CIF7cKsJoOCoBw3rsfaJfJzgm/lhyFdY Jhmgun6h7vwiTu/nS5SYvKZu05L87KjCngEv2ixeVUcuK5aSD/TvFryG0i6RSdoHjA B8Em5h3TE0sUFhwRM2WLHq5SVg6G6xaXC16Vqx08= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4B2FE38582A1 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4B2FE38582A1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708722947; cv=none; b=R5fphEaJ25ARDnYZjtrL5vstaLsx7Y8u6O2PFySiGwxrinzaeqqt6OkQxl/+C89MO9Odxim1IoDJvgsYxrHSs0xtdU/vE5lXbctUR0hkYrPxhfalaHB8RvGgGBEakohUkyqpknThSjGJGqcwg6yvjTqSwG5f61ja9bkcsgymNz8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708722947; c=relaxed/simple; bh=V8mFcIkOJ/gHOl3b++B11TKrK8xCFwvojhvpXuYu5do=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=lSAvODWzn5/hsikU/FYfwsfDKhgxc5t2Mh4SGzuvwA2h9XKIFagtdGvtQfeee5qBWadrr/IJVUeWhHrwicJQXGy+p+kcCvY1pjCWuxx+yFoCTa0Ut5L2cyHeauVouD01UWH2nC8z8X219tthkZ7pOstml1LuDRh0IjvAVKBfR74= ARC-Authentication-Results: i=1; server2.sourceware.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708722936; x=1709327736; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8icTFoXaZAn3gIunsbxuyMSzauPG9Ycccg0DTI6ehkI=; b=teJ71TJWS8yWiMfJn6952kStS/O2w1EPZFe6ieZfZpibAwd2wfNmE+HAGN1wz9ypev gjSScMNJkYjoaVD8RwhaKoPWXRxmAmfDzqSshqOYYq8vhJYNIhi5RguSeG/02TrGcvMC /brxuGk6xZq+IhkH6Rt8pcBD6NJ4S8KxvI8qbNUDNa6uXrLUMQrqQRHCAMAH6aJZRP3q AGh+CkUecmdURhilCKXSssbqv0Fc7oUunqjudpJvWEoV/kthyA72H+6/NxQrYeDp5n4m 9+aAcEMyX+S4o3OLpgNgHGs4j4zOEoeArM1dwOlksjed2HJdzqaKqMzt4rQbk8OI4IGx u5Ig== X-Gm-Message-State: AOJu0YxKb3CqPT415xcQIeDomamX79HYmCxYa3HlEANfPEzo0cLNm0A9 lTJhP3okbvpUuWwJ1gyASu5dJ66jfNv+8QEGd9aOqRhvq8cr6gDqLknF5a8X01qlEDNEfqhiDgZ HJbcj2SAd7kwiq2vmrN0p3cFuM+jviSVuigM= X-Google-Smtp-Source: AGHT+IHAhBfuSeZE+kZqBDKZNmlHJoq90YyAbt1NlelZcZW3ECJN2Ma+d6UQbnMKYob5YrVCqx9pGCRniO0Vr4RuGyw= X-Received: by 2002:a2e:a265:0:b0:2d2:74ee:bec1 with SMTP id k5-20020a2ea265000000b002d274eebec1mr189492ljm.48.1708722936198; Fri, 23 Feb 2024 13:15:36 -0800 (PST) MIME-Version: 1.0 References:

In-Reply-To: Date: Fri, 23 Feb 2024 22:15:09 +0100 Message-ID: Subject: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ? To: cygwin AT cygwin DOT com X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 List-Id: General Cygwin discussions and problem reports List-Archive: List-Post: List-Help: List-Subscribe: , From: Dan Shelton via Cygwin Reply-To: Dan Shelton Content-Type: text/plain; charset="utf-8" Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 41NLGuHX023792 On Fri, 23 Feb 2024 at 19:45, Roland Mainz via Cygwin wrote: > > On Fri, Feb 23, 2024 at 4:47 PM Corinna Vinschen via Cygwin > wrote: > > On Feb 23 14:03, Roland Mainz via Cygwin wrote: > > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin > > > wrote: > > > > On Feb 22 18:38, Roland Mainz via Cygwin wrote: > > > > > If I switch the current user's group with /usr/bin/newgrp, how can a > > > > > (native) Win32 process use > > > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which > > > > > group is the new "current group" (e.g. which |TokenInformationClass| > > > > > should I use) ? > > > > > > > > PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE); > > > > NTSTATUS status; > > > > ULONG size; > > > > > > > > status = NtQueryInformationToken (hProcToken, TokenPrimaryGroup, > > > > sidbuf, SECURITY_MAX_SID_SIZE, > > > > &size); > > > > > > Well, it works in the case of an "hello world" application, but if I > > > stuff that into the nfsd_daemon (NFSv4.1 ms-nfs41-client client > > > daemon) it always prints the default primary group, even if the > > > current thread should impersonate another user - or in this case even > > > the same user, but a different primary group (e.g. see > > > https://github.com/kofemann/ms-nfs41-client/blob/master/sys/nfs41_driver.c#L1367). > > > > > > Do you have any idea what is going wrong in this case ? > > > > Not sure about that. I'm not familiar with driver development under > > Windows. > > Me neither, I'm still new to this whole Windows kernel stuff (coming > from SUN&Solaris engineering), but as we need a NFSv4 filesystem > client at work I'm basically forced at knifepoint to learn as fast as > I can... ;-/ > > > I'd expect that you get the token of the calling thread or, in > > this case, process as is. > > I think it's the calling thread which makes the Win32 syscall, then > the MiniRedirector driver (nfs41_driver.sys) gets that security > context, and uses that to set the impersonation stuff when making the > upcall to the userland part (nfsd_debug.exe), so that daemon thread > can impersonate the caller. > > > However, did you try this with a primary group SID being part of the > > token's supplementary group list, or did you try this with some > > arbitrary group SID? > > I tried it like this: > 1. On the Windows machine I created these two new groups: > ---- snip ---- > WINHOST1:~$ net localgroup cygwingrp1 /add > WINHOST1:~$ net localgroup cygwingrp2 /add > WINHOST1:~$ getent group cygwingrp1 > cygwingrp1:S-1-5-21-3286904461-661230000-4220857270-1003:197611: > WINHOST1:~$ getent group cygwingrp2 > cygwingrp2:S-1-5-21-3286904461-661230000-4220857270-1004:197612: > ---- snip ---- > > On the Linux NFSv4 server side I added these groups too, and added > group membership for the matching user: > ---- snip ---- > root AT DERFWNB4966:~# groupadd -g 197611 cygwingrp1 > root AT DERFWNB4966:~# groupadd -g 197612 cygwingrp2 > root AT DERFWNB4966:~# usermod -a -G cygwingrp1 roland_mainz > root AT DERFWNB4966:~# usermod -a -G cygwingrp2 roland_mainz > ---- snip ---- > > After that /usr/bin/chgrp on Cygwin works on the NFSv4.1 filesystem, > but if I do a /usr/bin/newgrp+/usr/bin/touch it will not create files > with that new group, because nfsd_debug.exe only sees the default > primary group, not the new primary group set by /usr/bin/newgrp. > > Or is there a mistake - do I have to add the current user to the > Windows localgroup first somehow (like usermod on Linux) ? Yes, there is a mistake. You have to add the intended user to that group. Example: net localgroup mywingrp1 mywinuser44 /add HOWEVER, there is another Cygwin bug: "getent group mywingrp1" does not list any group members, even after "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX violation. Dan -- Dan Shelton - Cluster Specialist Win/Lin/Bsd -- 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