From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 05 04:36:36 2019 Received: (at submit) by debbugs.gnu.org; 5 Jul 2019 08:36:36 +0000 Received: from localhost ([127.0.0.1]:52342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hjJhs-0004ba-Da for submit@debbugs.gnu.org; Fri, 05 Jul 2019 04:36:36 -0400 Received: from lists.gnu.org ([209.51.188.17]:40454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hjJhp-0004bQ-4Z for submit@debbugs.gnu.org; Fri, 05 Jul 2019 04:36:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57796) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjJho-0000eL-2T for bug-guix@gnu.org; Fri, 05 Jul 2019 04:36:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hjJhm-0001QC-E9 for bug-guix@gnu.org; Fri, 05 Jul 2019 04:36:32 -0400 Received: from mx1.cock.li ([185.10.68.5]:57921 helo=cock.li) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hjJhl-0001MI-RP for bug-guix@gnu.org; Fri, 05 Jul 2019 04:36:30 -0400 Date: Fri, 5 Jul 2019 02:36:21 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1562315785; bh=p7HCKNhU2HswCeulPkEXT2m62X0y23+euKfPp/FoiW8=; h=Date:From:To:Subject:From; b=zN96teQzmCRL+ipAbEmiImLpkddnhyNEvaUUIZIURxaL+0Tvxr7vnI+POnSkpS9Al FAx0G1yfrIjHSDBivYxVQAtUwq+IQW1VH/q2z+PHIVEre2P90WinaxXUUyW0Zk7766 2KDBJN+ywtbbyMkDqO4X3h7bUyhtrlL60tJmQyNzDAWhNYF9KYdozmjUiJ7JcKPPQn YdO0eLDkyqVh8DBA5mRrn6dmS7oAwZBh2LX9D8f2ICbHvI1U6rizAdUOMkax8o7k7L xvc+7zDO7BtZVHTDqEVPoy253hBrq/5eEAoYGDY6foNwm+rgaYzt6mNGjgkynriL09 /E5vWeTpy3x1Q== From: ison To: bug-guix@gnu.org Subject: GDM files have incorrect owner after temporarily replacing with SDDM Message-ID: <20190705083620.lbzu7a33awbymh3d@cf0> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20180716 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 185.10.68.5 X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) After replacing GDM with SDDM in my Guix System config (to test Wayland) and then reverting back to my old config and reconfiguring GDM would crash (printing out around 500 lines about creating a seat) I also tried rolling back to the generation I had before using SDDM and it would still crash. In both instances I also tried "herd restart xorg-server" but same problem. I then checked the log file /var/log/gdm/greeter.log which had errors such as: ------------------- Fatal server error: (EE) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-720.log" ------------------- And then I could verify that files inside of /var/lib/gdm had incorrect ownership of 9##:gdm where 9## was some 3-digit number I can't remember now. (note: the directory itself /var/lib/gdm still had correct ownership gdm:gdm) I then manually fixed the ownership with: chown -R gdm:gdm /var/lib/gdm and GDM successfully came up without crashing. The relevant portion of my config when I replaced GDM with SDDM was: ------------------------------- (operating-system ... (services (cons* ... (sddm-service (sddm-configuration (display-server "wayland"))) ;; Return %desktop-services with GDM removed (remove (lambda (service) (eq? (service-kind service) gdm-service-type)) %desktop-services)))) ------------------------------- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 13 09:24:50 2021 Received: (at 36508) by debbugs.gnu.org; 13 Apr 2021 13:24:50 +0000 Received: from localhost ([127.0.0.1]:59318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWJ29-0004Ad-Mh for submit@debbugs.gnu.org; Tue, 13 Apr 2021 09:24:50 -0400 Received: from mout-p-201.mailbox.org ([80.241.56.171]:18516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWJ28-0004AL-Nc for 36508@debbugs.gnu.org; Tue, 13 Apr 2021 09:24:49 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4FKRCt4D9fzQjy8; Tue, 13 Apr 2021 15:24:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:subject:subject :message-id:from:from:date:date:received; s=mail20150812; t= 1618320275; bh=vGJi47T/LMs4Dq1TDG334T1VqMJQEvuDHoTf9xbm4Es=; b=s z4AjoN2cm30nTVBOi9TKwlh7UxRyEVd1UKX/veUqXzwj1cFQtYbeLwsuvo4XdHde UJnJGol21mgnvWwcpot8vqGgMKo/TJ94AfyuNccDTWKG6sVlMer9gq/Z1XhAEJft QVE8VB5TpINxKb7qGdZ4TaB0pJPwZM3wYKB7QhSy1MWhaEYlzQUw7AkPpDS+GnGN et9+kZ1SldJ8FDvUHZ35VIOUIOLjf8M4Vjh+HLDiHKgFhYYH/KrjI/NRtOR+a6J3 X0NuHJBD/zx3CgPPi3n7Q+8ebuxk6wOEfOYwsxEAh4yPHTvTcsJ8ettgtO3DN41M ymNiIArhWaXeuwQ+BsXVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1618320280; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=rLiK3gLIJ8/HiIhETWjvw3yfbb0+bZCdmxVmS1tNyss=; b=XeDjmT3S454yytMwJBFE0Odjzj134EtpptfxQZfGP6CLu612oqU36s2EiCqselO+7QOdY6 XP2uEG7naQQBP787VyBUOkj82uVoONLEiF9Y/Kgqx71bx7b5tOdvuYEo+P2MxC+b+OP9JE 5kSf/kflyaiqkMN2jWT5+U3GiKp15ChyzmuJ+pPE28AanxrwWuCMl5E46cFM/JVbTP76DN osyJPbMS2QNeUXPbxrz17vSrMN2Mb9ZYPdMhYDzT0syXy+0yt67wES8pDxuYilTiFYsGET 2euhZ4iAiXVUYB95PdtO8uxT3Csq7Jtp8Hh8B+xeFQtT4T7o9A+9f/iWngiGrA== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id yMGIi3yscDoP; Tue, 13 Apr 2021 15:24:35 +0200 (CEST) Date: Tue, 13 Apr 2021 15:24:35 +0200 (CEST) From: Brendan Tildesley To: "36508@debbugs.gnu.org" <36508@debbugs.gnu.org> Message-ID: <1576552162.14721.1618320275616@office.mailbox.org> Subject: GDM files have incorrect owner after temporarily removing service MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14719_1225470587.1618320275370" X-Priority: 3 Importance: Normal X-MBO-SPAM-Probability: * X-Rspamd-Score: 1.33 / 15.00 / 15.00 X-Rspamd-Queue-Id: 47E131811 X-Rspamd-UID: 84e62a X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: =?UTF-8?Q?Ludovic_Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) ------=_Part_14719_1225470587.1618320275370 Content-Type: multipart/alternative; boundary="----=_Part_14720_877439344.1618320275371" ------=_Part_14720_877439344.1618320275371 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I recently encountered what is likely the same bug. The directory /var/lib/gdm had the correct permissions gdm:gdm, but all the files inside had something like 973:gdm a43e9157ef479e94c19951cc9d228cf153bf78ee is supposed to fix this (duplicate bug 37423) but it only checks the permissions of /var/lib/gdm/ itself. Not all of the files in it. This explains why in my case it failed to fix the permissions, because the directory was gdm:gdm. How it got that way I don't know, and infact it doesn't really matter. The directory is mutable, and thus can theoretically be changed for any number of reasons. Therefore if we wish for Guix to be robust with it's Functional design, and have meaningful rollbacks, we perhaps have no choice but to assert the required invariants like these on mutable files. A better solution may be to make it fully chown -R on reconfigure, but not each time on boot? I've attached an untested patch with a suggested solution of making %gdm-activation operate every single time, instead of just after checking /var/lib/gdm. ------=_Part_14720_877439344.1618320275371 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
I recently encountered what is likely the same bug. The directory /var/lib/gdm
had the correct permissions gdm:gdm, but all the files inside had something like
973:gdm

a43e9157ef479e94c19951cc9d228cf153bf78ee is supposed to fix this (duplicate bug
37423) but it only checks the permissions of /var/lib/gdm/ itself. Not all of
the files in it. This explains why in my case it failed to fix the permissions,
because the directory was gdm:gdm. How it got that way I don't know, and infact
it doesn't really matter. The directory is mutable, and thus can theoretically be
changed for any number of reasons. Therefore if we wish for Guix to be robust
with it's Functional design, and have meaningful rollbacks, we perhaps have no
choice but to assert the required invariants like these on mutable files.

A better solution may be to make it fully chown -R on reconfigure, but not each time
on boot?

I've attached an untested patch with a suggested solution of making
%gdm-activation operate every single time, instead of just after checking
/var/lib/gdm.


------=_Part_14720_877439344.1618320275371-- ------=_Part_14719_1225470587.1618320275370 Content-Type: text/x-patch; charset=ISO-8859-1; name=0001-services-gdm-Correctly-set-ownership-on-var-lib-gdm.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=0001-services-gdm-Correctly-set-ownership-on-var-lib-gdm.patch X-Part-Id: c69ffe53ac4e4a34a93d63e62b794a98 RnJvbSAzMWNiNmRiZDc1NmFmNjk1YmQ2YTFmNGQ0Yzg5YjQyMzY3YjEzMzA3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCcmVuZGFuIFRpbGRlc2xleSA8bWFpbEBicmVuZGFuLnNjb3Q+ CkRhdGU6IFR1ZSwgMTMgQXByIDIwMjEgMjM6MDQ6MjggKzEwMDAKU3ViamVjdDogW1BBVENIXSBz ZXJ2aWNlczogZ2RtOiBDb3JyZWN0bHkgc2V0IG93bmVyc2hpcCBvbiAvdmFyL2xpYi9nZG0uCgoq IGdudS9zZXJ2aWNlcy94b3JnLnNjbSAoJWdkbS1hY3RpdmF0aW9uKTogQWx3YXlzIGNob3duIC92 YXIvbGliL2dkbSwKaW5zdGVhZCBvZiBvbmx5IHdoZW4gaXQgYXBwZWFycyB0byBiZSBjb3JyZWN0 LCBiZWNhdXNlIGl0J3Mgc3RpbGwKcG9zc2libGUgdGhlIGZpbGVzIGluc2lkZSBjb3VsZCBiZSB3 cm9uZyBhbmQgYnJlYWsgR0RNLiBJIGVuY291bnRlcmVkCnRoaXMgb25jZTogaHR0cHM6Ly9pc3N1 ZXMuZ3VpeC5nbnUub3JnLzM2NTA4IC4KClBlcmhhcHMgaXQgaXMgd2l0aCBnb29kIGludGVudGlv bnMgdG8gdHJ5IG5vdCBydW5uaW5nIHRoaXMgY29kZSBldmVyeQpzaW5nbGUgdGltZSBvbiBib290 LCBidXQgd2hlbiBpdCBmYWlscywgdGhlIGNvbnNlcXVlbmNlIGlzIHRoYXQgR0RNIGNhbgpicmVh ayBub3QganVzdCBmb3IgdGhlIGN1cnJlbnQgcmV2aXNpb24sIGJ1dCBhbGwgcHJldmlvdXMgcm9s bGJhY2sKc3lzdGVtcyBpbiBHUlVCIHdpbGwgZmFpbCwgYW5kIHN1YnNlcXVlbnQgcmVjb25maWd1 cmUtaW5ncyBmYWlsCnRvby4gVGhhdCB0b3RhbGx5IGRlc3Ryb3lzIGEgZGVza3RvcCBzeXN0ZW0g YW5kIG91ciByb2xsYmFjawpmdW5jdGlvbmFsbHksIHdoaWNoIGlzIG11Y2ggbXVjaCB3b3JzZSEK LS0tCiBnbnUvc2VydmljZXMveG9yZy5zY20gfCAxNSArKysrKy0tLS0tLS0tLS0KIDEgZmlsZSBj aGFuZ2VkLCA1IGluc2VydGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2du dS9zZXJ2aWNlcy94b3JnLnNjbSBiL2dudS9zZXJ2aWNlcy94b3JnLnNjbQppbmRleCAxN2Q5ODNm ZjhkLi5hMjA2YzdjOTNhIDEwMDY0NAotLS0gYS9nbnUvc2VydmljZXMveG9yZy5zY20KKysrIGIv Z251L3NlcnZpY2VzL3hvcmcuc2NtCkBAIC04NjEsMTYgKzg2MSwxMSBAQCB0aGUgR05PTUUgZGVz a3RvcCBlbnZpcm9ubWVudC4iKQogCiAgICAgICAgIChsZXQqICgoZ2RtIChnZXRwd25hbSAiZ2Rt IikpCiAgICAgICAgICAgICAgICAodWlkIChwYXNzd2Q6dWlkIGdkbSkpCi0gICAgICAgICAgICAg ICAoZ2lkIChwYXNzd2Q6Z2lkIGdkbSkpCi0gICAgICAgICAgICAgICAoc3QgIChzdGF0ICIvdmFy L2xpYi9nZG0iICNmKSkpCi0gICAgICAgICAgOzsgUmVjdXJzZSBpbnRvIC92YXIvbGliL2dkbSBv bmx5IGlmIGl0IGhhcyB3cm9uZyBvd25lcnNoaXAuCi0gICAgICAgICAgKHdoZW4gKGFuZCBzdAot ICAgICAgICAgICAgICAgICAgICAgKG9yIChub3QgKD0gdWlkIChzdGF0OnVpZCBzdCkpKQotICAg ICAgICAgICAgICAgICAgICAgICAgIChub3QgKD0gZ2lkIChzdGF0OmdpZCBzdCkpKSkpCi0gICAg ICAgICAgICAoZm9yLWVhY2ggKGxhbWJkYSAoZmlsZSkKLSAgICAgICAgICAgICAgICAgICAgICAg IChjaG93biBmaWxlIHVpZCBnaWQpKQotICAgICAgICAgICAgICAgICAgICAgIChmaW5kLWZpbGVz ICIvdmFyL2xpYi9nZG0iCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIzpkaXJl Y3Rvcmllcz8gI3QpKSkpKSkpCisgICAgICAgICAgICAgICAoZ2lkIChwYXNzd2Q6Z2lkIGdkbSkp KQorICAgICAgICAgIChmb3ItZWFjaCAobGFtYmRhIChmaWxlKQorICAgICAgICAgICAgICAgICAg ICAgIChjaG93biBmaWxlIHVpZCBnaWQpKQorICAgICAgICAgICAgICAgICAgICAoZmluZC1maWxl cyAiL3Zhci9saWIvZ2RtIgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjOmRpcmVj dG9yaWVzPyAjdCkpKSkpKQogCiAoZGVmaW5lIGRidXMtZGFlbW9uLXdyYXBwZXIKICAgKHByb2dy YW0tZmlsZQotLSAKMi4zMS4xCgo= ------=_Part_14719_1225470587.1618320275370-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 13 16:53:24 2021 Received: (at 36508) by debbugs.gnu.org; 13 Apr 2021 20:53:24 +0000 Received: from localhost ([127.0.0.1]:60958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWQ2F-0002uu-Ra for submit@debbugs.gnu.org; Tue, 13 Apr 2021 16:53:24 -0400 Received: from world.peace.net ([64.112.178.59]:35746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWQ2E-0002uh-US for 36508@debbugs.gnu.org; Tue, 13 Apr 2021 16:53:23 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lWQ28-0007Iv-OO; Tue, 13 Apr 2021 16:53:16 -0400 From: Mark H Weaver To: Brendan Tildesley , 36508@debbugs.gnu.org Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <1576552162.14721.1618320275616@office.mailbox.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> Date: Tue, 13 Apr 2021 16:51:35 -0400 Message-ID: <87czuxsya5.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Brendan, Brendan Tildesley via Bug reports for GNU Guix writes: > I recently encountered what is likely the same bug. The directory /var/lib/gdm > had the correct permissions gdm:gdm, but all the files inside had something like > 973:gdm The underlying problem here, which I've also experienced, is that if you reconfigure your system with fewer users/groups, and then later add those users/groups back, there is no guarantee that they will be assigned the same UIDs and GIDs. This problem is made much worse by the fact that files may be left around, e.g. in /var, with the old UIDs and GIDs. In your case, I guess that the 'gdm' user was previously assigned UID 973, but now it has been given a different UID. In my case, after reconfiguring to a minimal system and later switching back to a full GNOME-based desktop system, I found that many files and directories in /var had the wrong owner or group. Here's what I saw before I cleaned things up: --8<---------------cut here---------------start------------->8--- root@jojen ~# ls -l /var/lib/ total 4 drwxr-xr-x 1 colord colord 40 Mar 28 2017 colord drwx------ 1 995 978 56 Sep 3 02:10 gdm drwx------ 1 root root 30400 Dec 25 01:55 NetworkManager -rw------- 1 root root 512 Dec 25 01:35 random-seed drwxr-xr-x 1 colord colord 164 Dec 28 2017 sddm drwx------ 1 tor tor 178 Dec 19 21:28 tor drwx------ 1 root root 20 Sep 5 01:32 udisks2 drwxr-xr-x 1 root root 274 Dec 25 01:55 upower drwxr-xr-x 1 root root 86 Mar 28 2017 wicd root@jojen ~# ls -la /var/lib/gdm/ total 4 drwx------ 1 995 978 56 Sep 3 02:10 . drwxr-xr-x 1 root root 750 Dec 25 01:59 .. drwxr-xr-x 1 994 colord 64 Sep 3 02:10 .cache drwx------ 1 994 colord 54 Sep 3 02:10 .config -rw------- 1 994 colord 16 Sep 3 02:10 .esd_auth drwxr-xr-x 1 994 colord 10 Sep 3 02:10 .local root@jojen ~# --8<---------------cut here---------------end--------------->8--- Given the fact that existing files and directories in /var can *effectively* have their ownership changed, I think that this issue could be a security risk. There's some discussion of this issue at , although I'm not sure that Danny's suggested solution is practical. Here's one idea: when activating a system, *never* delete users or groups if files still exist that are owned by those users/groups. Checking all filesystems would likely be too expensive, but perhaps it would be sufficient to check certain directories such as /var, /etc, and possibly the top directory of /home. What do you think? Mark From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 14 00:32:07 2021 Received: (at 36508) by debbugs.gnu.org; 14 Apr 2021 04:32:07 +0000 Received: from localhost ([127.0.0.1]:33119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWXCB-0008A4-8p for submit@debbugs.gnu.org; Wed, 14 Apr 2021 00:32:07 -0400 Received: from mout-p-102.mailbox.org ([80.241.56.152]:15662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWXC9-00089V-1j for 36508@debbugs.gnu.org; Wed, 14 Apr 2021 00:32:06 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4FKqLk5FWMzQk1B; Wed, 14 Apr 2021 06:31:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-type:content-type:mime-version :subject:subject:references:in-reply-to:message-id:from:from :date:date:received; s=mail20150812; t=1618374714; bh=ouPL1qs6om xiQMs7gkF+Ue3RkqqmKGDxWSkqSIO7ZNQ=; b=eAp9VdEkykKOE+HGfgoKQBjJhx yryIWbJ1CtU6hG9hIAsb93f/z8RRllTxiP90gTGu81zyNPiAbixre2toJBdudC5A 3Lcvl9QPSmFJZbhjGgvyuWpm5KftRF+bof4C18tapXnbMKE04B4sX0dj+7Bn4IO2 2IE+2CAe/2YoLHfgbFyGXJFeI9L3d0cIZPhA6jJB4828rZSPimQftcKghTpklgXf XqGPBAFe6f5Av10CCe7pAQ8iffyoubgDvlciC8x4xYrk43FyIflvB7myuFs9J3O4 Rxrke7p2NlGZ9Vy5ItX2AK0Bl18F5N84TLmqYViLpcP4INqHyKrvbDMgsrwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1618374716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C62iV6IxQGLQIxbZx1DNdC1AUs0Vor4kHPo/eDxfr2M=; b=XGv7labxwrvcBCvki7nr1izMqCQMd1JxqjqEmfPSMSXirRGd6+74NGoKdY09bkDhwgEoyM 0u++AkanPW/qQK6/uKLvlQtMzNV+cgoYWzGcQ4ll8yMXIjZw4Dmind4mUb/iKr7AjXjcMF frMhzB2AsNZwdHc8oJGHXaPJufOzaLwfNEyrbcWeTnjpWNTTZlJlycta51yhxLyXkikwTJ uWZN/zyXuQyouYdajTcS/3DcROF/hKp5O+hBwJt7Bv5iEli4dZMZIkOK/RAgVT+Fyzw3tL VjeuLMfOQtx3fki8jhLAZYzFTCTa98p8GFmOUyNik3dPj6tw99LxapSCOFa5IQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id fyRO9kQPTyV9; Wed, 14 Apr 2021 06:31:54 +0200 (CEST) Date: Wed, 14 Apr 2021 06:31:54 +0200 (CEST) From: Brendan Tildesley To: 36508@debbugs.gnu.org Message-ID: <461701204.22088.1618374714507@office.mailbox.org> In-Reply-To: <87czuxsya5.fsf@netris.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-MBO-SPAM-Probability: X-Rspamd-Score: -6.44 / 15.00 / 15.00 X-Rspamd-Queue-Id: 5CDF017CC X-Rspamd-UID: 553017 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: Mark H Weaver , =?UTF-8?Q?Ludovic_Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > On 04/13/2021 10:51 PM Mark H Weaver wrote: > > > Hi Brendan, > > Brendan Tildesley via Bug reports for GNU Guix > writes: > > > I recently encountered what is likely the same bug. The directory /var/lib/gdm > > had the correct permissions gdm:gdm, but all the files inside had something like > > 973:gdm > > The underlying problem here, which I've also experienced, is that if you > reconfigure your system with fewer users/groups, and then later add > those users/groups back, there is no guarantee that they will be > assigned the same UIDs and GIDs. > > This problem is made much worse by the fact that files may be left > around, e.g. in /var, with the old UIDs and GIDs. > > In your case, I guess that the 'gdm' user was previously assigned UID > 973, but now it has been given a different UID. > > In my case, after reconfiguring to a minimal system and later switching > back to a full GNOME-based desktop system, I found that many files and > directories in /var had the wrong owner or group. Here's what I saw > before I cleaned things up: > > --8<---------------cut here---------------start------------->8--- > root@jojen ~# ls -l /var/lib/ > total 4 > drwxr-xr-x 1 colord colord 40 Mar 28 2017 colord > drwx------ 1 995 978 56 Sep 3 02:10 gdm > drwx------ 1 root root 30400 Dec 25 01:55 NetworkManager > -rw------- 1 root root 512 Dec 25 01:35 random-seed > drwxr-xr-x 1 colord colord 164 Dec 28 2017 sddm > drwx------ 1 tor tor 178 Dec 19 21:28 tor > drwx------ 1 root root 20 Sep 5 01:32 udisks2 > drwxr-xr-x 1 root root 274 Dec 25 01:55 upower > drwxr-xr-x 1 root root 86 Mar 28 2017 wicd > root@jojen ~# ls -la /var/lib/gdm/ > total 4 > drwx------ 1 995 978 56 Sep 3 02:10 . > drwxr-xr-x 1 root root 750 Dec 25 01:59 .. > drwxr-xr-x 1 994 colord 64 Sep 3 02:10 .cache > drwx------ 1 994 colord 54 Sep 3 02:10 .config > -rw------- 1 994 colord 16 Sep 3 02:10 .esd_auth > drwxr-xr-x 1 994 colord 10 Sep 3 02:10 .local > root@jojen ~# > --8<---------------cut here---------------end--------------->8--- > > Given the fact that existing files and directories in /var can > *effectively* have their ownership changed, I think that this issue > could be a security risk. Yes and they could change for any reason under the sun, and so we have no choice but to set them right on service activation. Guix system rollbacks should be a supported feature of Guix, not just a gimmick that falls out of its design. It should be that a Guix user could leave their system for 5 years, and then do a guix pull; guix system reconfigure in the year 2026. Perhaps at that time the new system will break, and then its desirable that they can rollback to the previous generation. So what fixes we put in to Guix services today need to consider not just how files could have changed in the past, but how they might change in breaking ways in the future, within reason. I don't know off the top of my head of any way that can be done other than to have chmod -R gdm:gdm /var/lib/gdm always executed. > > There's some discussion of this issue at , > although I'm not sure that Danny's suggested solution is practical. > > Here's one idea: when activating a system, *never* delete users or > groups if files still exist that are owned by those users/groups. > Checking all filesystems would likely be too expensive, but perhaps it > would be sufficient to check certain directories such as /var, /etc, and > possibly the top directory of /home. > > What do you think Wouldn't that imply that uids could be randomly different on different systems with the same configuration, and then remain statically different permanently? We want as little randomness and moving parts as possible. It's yet another way the system is not actually Functional, but has state. Seems this bug spans 3 or so different bug reports. In http://issues.guix.gnu.org/45571 I commented that Nix uses hard coded id's, sorta like how ports are allocated for a purpose: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix Perhaps you are thinking of other kinds of security issues that could be caused that I'm not thinking of. In that case maybe Nix devs have already made the best choice by making them static? ... After all, if the permissions can change, then it is possible another user could actually modify the contents of /var/lib/gdm its self, thereby infecting other users, if for some reason that other malicious user gets allocated that ID. That further points towards static ID's like Nix has as a solution. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 14 06:32:59 2021 Received: (at 36508) by debbugs.gnu.org; 14 Apr 2021 10:32:59 +0000 Received: from localhost ([127.0.0.1]:33669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWcpP-0000w2-EF for submit@debbugs.gnu.org; Wed, 14 Apr 2021 06:32:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWcpN-0000vp-F2 for 36508@debbugs.gnu.org; Wed, 14 Apr 2021 06:32:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40035) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWcpG-0007E9-Nq; Wed, 14 Apr 2021 06:32:51 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=34782 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lWcpG-0000TX-9X; Wed, 14 Apr 2021 06:32:50 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Mark H Weaver Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 25 Germinal an 229 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Wed, 14 Apr 2021 12:32:48 +0200 In-Reply-To: <87czuxsya5.fsf@netris.org> (Mark H. Weaver's message of "Tue, 13 Apr 2021 16:51:35 -0400") Message-ID: <875z0pgnqn.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Mark, Mark H Weaver skribis: > Brendan Tildesley via Bug reports for GNU Guix > writes: > >> I recently encountered what is likely the same bug. The directory /var/l= ib/gdm >> had the correct permissions gdm:gdm, but all the files inside had someth= ing like >> 973:gdm > > The underlying problem here, which I've also experienced, is that if you > reconfigure your system with fewer users/groups, and then later add > those users/groups back, there is no guarantee that they will be > assigned the same UIDs and GIDs. Yes. The patch Brendan posted LGTM (though I=E2=80=99m surprised the directory i= tself can have the right UID/GID while files inside it don=E2=80=99t; perhaps thi= s was made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns the home directory unconditionally.) Note that there are other places, in addition to GDM, where we forcefully reset the UID/GID of the home directory (e.g., for the =E2=80=98knot-resolver=E2=80=99 service.) My preferred solution to this would be to unconditionally chown -R home directories upon activation (for efficiency, it would be best if we could do that if and only if the home directory itself has wrong ownership). Thoughts? systemd-homed does something like that. The intuition here is that UIDs/GIDs are implementation details that should get out of the way. > There's some discussion of this issue at , > although I'm not sure that Danny's suggested solution is practical. > > Here's one idea: when activating a system, *never* delete users or > groups if files still exist that are owned by those users/groups. > Checking all filesystems would likely be too expensive, but perhaps it > would be sufficient to check certain directories such as /var, /etc, and > possibly the top directory of /home. How would you determine which directories to look at though? What if we miss an important one? Note that the ID allocation strategy in (gnu build accounts) ensures UIDs/GIDs aren=E2=80=99t reused right away (same strategy as implemented by Shadow, etc.). So if you remove =E2=80=9Cbob=E2=80=9D, then add =E2=80=9Ca= lice=E2=80=9D, =E2=80=9Calice=E2=80=9D won=E2=80=99t be able to access the left-behind /home/bob because it has a different UID. Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 14 08:21:19 2021 Received: (at 36508) by debbugs.gnu.org; 14 Apr 2021 12:21:19 +0000 Received: from localhost ([127.0.0.1]:33860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWeWE-0005xC-SE for submit@debbugs.gnu.org; Wed, 14 Apr 2021 08:21:19 -0400 Received: from mout-p-101.mailbox.org ([80.241.56.151]:24040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWeWC-0005wu-MG for 36508@debbugs.gnu.org; Wed, 14 Apr 2021 08:21:18 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4FL1m6653DzQjwf; Wed, 14 Apr 2021 14:21:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-type:content-type:mime-version :subject:subject:references:in-reply-to:message-id:from:from :date:date:received; s=mail20150812; t=1618402864; bh=us9OXY5O5p GpfHLemJ5PLTjoywNrQkvn+AAnhigvAzs=; b=VAECrUpRBWVeYUy/WTvdZ/sEZm R4kkZqXlUhHtVc+0HgfFpcA4pwn0+7qVMMKqUFdZhz7L5DOAAAe+TiojnoXuFJTv Xzy6v1Sz7Sm4LVvQG78qke11RQSSacWSAzsWQRYCt9IjCsyJ3Ngk079wRmRKqAmP q1g7X/lJVdLwoG+BXlxfmGpsHiCUc2tL1YJl1wc6ASMbJMNMZu/emrcf/7tNcJZ4 MuU5a27wPP9Kuuabw/4GqwXb3T7wYhZ8D4tzpRQPAF88btP7bROrzqC33pz8mQ4W 5myz7WjjIeuCIBSco5zb2vWPiyjp16xqXqyUcYvakhwkHSzidjz9/EBktcpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1618402869; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q69mD9LGTrkxrzfmEZzwft414MS47zJTwr+PDEiit4Q=; b=fEZkH2tKz68kdsWqzjpg/f2305CvzkAlyGvpH5E9Gq8+qXO/ZhhARB8CKWtXPJHyBBJ9x4 Ii9BD6Yy8acxvonXm9jbP8+CxLUrwxws7GufuqxE5Eyw6XsqdpvnfvWv2h6XPpuF/hLQuP XvB8KlXy7zUIpKevQQm0FJDNtzpkDz8tD2kNS7EIjzTWx0jqTQOp76kob+cwItv75bpe55 icfoWhXdGWL+IIK/cfoVoBHdknOiqTLNlj+esxuklGwyUlXRIsaWLcPFLi91UgymAxg6lu KrwCLZs39ZrpB7Z7wezMy68/AQ0nH7FJh8ZbEDoBMzmPc1gFTv8cASihCmINSg== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id F7lSshsIBeZ3; Wed, 14 Apr 2021 14:21:04 +0200 (CEST) Date: Wed, 14 Apr 2021 14:21:03 +0200 (CEST) From: Brendan Tildesley To: 36508@debbugs.gnu.org Message-ID: <262720830.30369.1618402863721@office.mailbox.org> In-Reply-To: <875z0pgnqn.fsf@gnu.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-MBO-SPAM-Probability: X-Rspamd-Score: -6.13 / 15.00 / 15.00 X-Rspamd-Queue-Id: BE85217CF X-Rspamd-UID: 8bef7e X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: Mark H Weaver , =?UTF-8?Q?Ludovic_Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > On 04/14/2021 12:32 PM Ludovic Court=C3=A8s wrote: >=20 > =20 > Hi Mark, >=20 > Mark H Weaver skribis: >=20 > > Brendan Tildesley via Bug reports for GNU Guix > > writes: > > > >> I recently encountered what is likely the same bug. The directory /var= /lib/gdm > >> had the correct permissions gdm:gdm, but all the files inside had some= thing like > >> 973:gdm > > > > The underlying problem here, which I've also experienced, is that if yo= u > > reconfigure your system with fewer users/groups, and then later add > > those users/groups back, there is no guarantee that they will be > > assigned the same UIDs and GIDs. >=20 > Yes. >=20 > The patch Brendan posted LGTM (though I=E2=80=99m surprised the directory= itself > can have the right UID/GID while files inside it don=E2=80=99t; perhaps t= his was > made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns > the home directory unconditionally.) >=20 > Note that there are other places, in addition to GDM, where we > forcefully reset the UID/GID of the home directory (e.g., for the > =E2=80=98knot-resolver=E2=80=99 service.) >=20 > My preferred solution to this would be to unconditionally chown -R home > directories upon activation (for efficiency, it would be best if we > could do that if and only if the home directory itself has wrong > ownership). Thoughts? >=20 I'm confused. It sounds like you're suggesting to add the very IF condition= that my patch removes from %gdm-activation in order to fix the problem. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 10:25:02 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 14:25:02 +0000 Received: from localhost ([127.0.0.1]:38826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX2vW-0002cb-19 for submit@debbugs.gnu.org; Thu, 15 Apr 2021 10:25:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX2vT-0002cD-7J for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 10:25:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37295) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lX2vN-0000ou-4j; Thu, 15 Apr 2021 10:24:53 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=37672 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lX2vM-0005ij-L9; Thu, 15 Apr 2021 10:24:52 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Brendan Tildesley Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <262720830.30369.1618402863721@office.mailbox.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 26 Germinal an 229 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 15 Apr 2021 16:24:51 +0200 In-Reply-To: <262720830.30369.1618402863721@office.mailbox.org> (Brendan Tildesley's message of "Wed, 14 Apr 2021 14:21:03 +0200 (CEST)") Message-ID: <87o8ef8w24.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: Mark H Weaver , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi, Brendan Tildesley skribis: >> On 04/14/2021 12:32 PM Ludovic Court=C3=A8s wrote: [...] >> The patch Brendan posted LGTM (though I=E2=80=99m surprised the director= y itself >> can have the right UID/GID while files inside it don=E2=80=99t; perhaps = this was >> made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns >> the home directory unconditionally.) >>=20 >> Note that there are other places, in addition to GDM, where we >> forcefully reset the UID/GID of the home directory (e.g., for the >> =E2=80=98knot-resolver=E2=80=99 service.) >>=20 >> My preferred solution to this would be to unconditionally chown -R home >> directories upon activation (for efficiency, it would be best if we >> could do that if and only if the home directory itself has wrong >> ownership). Thoughts? >>=20 > I'm confused. It sounds like you're suggesting to add the very IF conditi= on that my > patch removes from %gdm-activation in order to fix the problem. I=E2=80=99d like to understand why the =E2=80=98if=E2=80=99 the patch remov= es was problematic. I think it relates to the commit above, but that needs more investigation. Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 14:11:10 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 18:11:10 +0000 Received: from localhost ([127.0.0.1]:39155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX6SM-0008NA-4Z for submit@debbugs.gnu.org; Thu, 15 Apr 2021 14:11:10 -0400 Received: from world.peace.net ([64.112.178.59]:40658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX6SK-0008Mx-AI for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 14:11:08 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lX6SE-0006ts-3P; Thu, 15 Apr 2021 14:11:02 -0400 From: Mark H Weaver To: Brendan Tildesley , 36508@debbugs.gnu.org Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <461701204.22088.1618374714507@office.mailbox.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <461701204.22088.1618374714507@office.mailbox.org> Date: Thu, 15 Apr 2021 14:09:17 -0400 Message-ID: <87pmyvifmf.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Brendan, Brendan Tildesley writes: > Guix system rollbacks should be a supported feature of Guix, not just a gimmick > that falls out of its design. It should be that a Guix user could leave their > system for 5 years, and then do a guix pull; guix system reconfigure in the year > 2026. Perhaps at that time the new system will break, and then its desirable > that they can rollback to the previous generation. This sounds like a good set of goals to strive for. I'm not sure that Guix, on its own, will be able to achieve reliable 5-year rollback. I think that would require _all_ software in Guix that maintains mutable state on disk to gracefully support downgrading to a version from 5 years earlier. Nonetheless, Guix can certainly do its part to try to ensure that multi-year rollbacks can work, and I agree that it's a good thing to keep in mind. > So what fixes we put in to > Guix services today need to consider not just how files could have changed in > the past, but how they might change in breaking ways in the future, within reason. It's a good thing to keep in mind, yes. > I don't know off the top of my head of any way that can be done other than to > have chmod -R gdm:gdm /var/lib/gdm always executed. I'm not necessarily opposed to doing that, at least as a temporary workaround for GDM, but I don't think this is a satisfactory solution to the larger problem. A few points: (1) I don't think we can assume that all files owned by a given user will be in that user's home directory, especially for "system" users. (2) I also don't think we can assume that all files in a user's home directory *should* be owned by that user. Even if it's true today, it might not be true tomorrow. (3) Groups don't even have home directories. > On 04/13/2021 10:51 PM Mark H Weaver wrote: >> >> There's some discussion of this issue at , >> although I'm not sure that Danny's suggested solution is practical. >> >> Here's one idea: when activating a system, *never* delete users or >> groups if files still exist that are owned by those users/groups. >> Checking all filesystems would likely be too expensive, but perhaps it >> would be sufficient to check certain directories such as /var, /etc, and >> possibly the top directory of /home. >> >> What do you think > > Wouldn't that imply that uids could be randomly different on different systems > with the same configuration, and then remain statically different permanently? Yes, and I agree that it's suboptimal. > We want as little randomness and moving parts as possible. It's yet another > way the system is not actually Functional, but has state. Agreed. Danny's suggested solution (UID = hash username) is clearly the optimal approach in many respects. It has the nice properties above. The practical problem I see with Danny's approach is that in order to make hash collisions sufficiently improbable, our UIDs and GIDs would need to be much larger than the 16 bits that is widely supported by POSIX software. With 16-bit UIDs, the probability of a collision would be 1.85% with 50 users, and 7.28% with 100 users. To adopt this approach, I think that our UIDs and GIDs would need to be at least 31 bits. These are the problems I see: (1) It's unlikely that all software in Guix robustly handles such large UIDs/GIDs. Desktop systems with UIDs/GIDs larger than 65533 have not been widely tested, as far as I know. (2) Even with 31 bit IDs, the probability of collisions would still be uncomfortably high when large numbers of users are present: with 10k users, the probability of hash collisions would be about 2.3%. (3) We'd need a transition plan for users' existing file systems. (4) It would be aesthetically unpleasant for our UIDs and GIDs to be random-looking numbers with 10 decimal digits. > Seems this bug spans 3 or so different bug reports. In http://issues.guix.gnu.org/45571 > I commented that Nix uses hard coded id's, sorta like how ports are allocated > for a purpose: > > https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix > > Perhaps you are thinking of other kinds of security issues that could be caused that > I'm not thinking of. I'm not sure what you're getting at here. The only security issue I've raised so far is that ownership of files can _effectively_ be changed when removing services and later adding them back. For example, in my case, 'colord' ended up being the owner of files in /var/lib/gdm. > In that case maybe Nix devs have already made the best choice by > making them static? That might well be true. At the present time, this is the option that seems most appealing to me. One possible approach would be to add a field to our 'operating-system' record that explicitly specifies a total mapping from user/group names to UIDs/GIDs. It could either be a procedure (to support Danny's hashing approach with its nice properties) or possibly also an alist for convenience. If any entries were missing, it would raise an error. One risk to this approach is that users could accidentally make a mess of their system if they made a mistake while changing that field. What do you think? Thanks, Mark From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 14:32:33 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 18:32:33 +0000 Received: from localhost ([127.0.0.1]:39182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX6n2-0000Sk-Qy for submit@debbugs.gnu.org; Thu, 15 Apr 2021 14:32:33 -0400 Received: from world.peace.net ([64.112.178.59]:40700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX6n1-0000SX-RH for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 14:32:32 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lX6mv-0008R2-6r; Thu, 15 Apr 2021 14:32:25 -0400 From: Mark H Weaver To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <875z0pgnqn.fsf@gnu.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> Date: Thu, 15 Apr 2021 14:30:40 -0400 Message-ID: <87lf9jiems.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ludovic Court=C3=A8s writes: > Note that there are other places, in addition to GDM, where we > forcefully reset the UID/GID of the home directory (e.g., for the > =E2=80=98knot-resolver=E2=80=99 service.) > > My preferred solution to this would be to unconditionally chown -R home > directories upon activation (for efficiency, it would be best if we > could do that if and only if the home directory itself has wrong > ownership). Thoughts? It might be okay to do this in specific cases like /var/lib/gdm, but I'm very uncomfortable doing it for *all* users, because: (1) We shouldn't assume that all files within a home directory are supposed to be owned by that user. (2) We shouldn't assume that all files owned by a user will be within their home directory. (3) We shouldn't assume that all files within a home directory are supposed to have the same 'group'. I, for one, have sometimes had subdirectories of my home directory with a different 'group', to either restrict or grant other users access to selected files or directories. (4) Groups do not, in general, have home directories. (5) I consider it unsatifactory for there to be *any* window of time during system activation when the ownership of files is incorrect. >> Here's one idea: when activating a system, *never* delete users or >> groups if files still exist that are owned by those users/groups. >> Checking all filesystems would likely be too expensive, but perhaps it >> would be sufficient to check certain directories such as /var, /etc, and >> possibly the top directory of /home. > > How would you determine which directories to look at though? What if we > miss an important one? Yes, that's a good point. I suppose that my idea above is not satifactory either. > Note that the ID allocation strategy in (gnu build accounts) ensures > UIDs/GIDs aren=E2=80=99t reused right away (same strategy as implemented = by > Shadow, etc.). So if you remove =E2=80=9Cbob=E2=80=9D, then add =E2=80= =9Calice=E2=80=9D, =E2=80=9Calice=E2=80=9D won=E2=80=99t > be able to access the left-behind /home/bob because it has a different > UID. This mechanism is insufficient, because it only avoids the problem if you add "alice" at the same time that "bob" is removed. If you remove "bob" during one system activation, and then later add "alice", then "alice" might well be able to access bob's left-behind files. In the case that I personally witnessed on my Guix system, files within /var/lib/gdm ended up with 'colord' as their group. That's not good. Increasingly, I'm leaning toward the idea that the complete mapping from names to IDs should somehow be explicitly given as part of the OS configuration, as I advocated in . What do you think? Thanks, Mark From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 14:37:09 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 18:37:09 +0000 Received: from localhost ([127.0.0.1]:39192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX6rU-0000a1-NV for submit@debbugs.gnu.org; Thu, 15 Apr 2021 14:37:08 -0400 Received: from world.peace.net ([64.112.178.59]:40712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX6rS-0000Z8-7w for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 14:37:07 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lX6rL-0000LE-VY; Thu, 15 Apr 2021 14:37:00 -0400 From: Mark H Weaver To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <875z0pgnqn.fsf@gnu.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> Date: Thu, 15 Apr 2021 14:35:16 -0400 Message-ID: <87im4nief4.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ludovic Court=C3=A8s writes: > My preferred solution to this would be to unconditionally chown -R home > directories upon activation I also wonder if this could lead to security flaws similar to CVE-2021-27851 , but perhaps 'chown' has been written carefully to avoid such problems. Mark From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 15:00:08 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 19:00:08 +0000 Received: from localhost ([127.0.0.1]:39212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX7Dk-00019I-ID for submit@debbugs.gnu.org; Thu, 15 Apr 2021 15:00:08 -0400 Received: from world.peace.net ([64.112.178.59]:40764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX7Dj-00017b-2a for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 15:00:07 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lX7Dc-00021r-Jm; Thu, 15 Apr 2021 15:00:00 -0400 From: Mark H Weaver To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <875z0pgnqn.fsf@gnu.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> Date: Thu, 15 Apr 2021 14:58:16 -0400 Message-ID: <87eefbidcs.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ludovic Court=C3=A8s writes: > Mark H Weaver skribis: > >> Here's one idea: when activating a system, *never* delete users or >> groups if files still exist that are owned by those users/groups. >> Checking all filesystems would likely be too expensive, but perhaps it >> would be sufficient to check certain directories such as /var, /etc, and >> possibly the top directory of /home. > > How would you determine which directories to look at though? What if we > miss an important one? I have another idea: Maintain historical mappings from user/group names to UIDs/GIDs, perhaps in some file in /etc, where entries are added but *never* automatically removed. When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the range of those mappings. Then, provide a UID/GID garbage collector, to be explicitly run by users if desired, which would scan all filesystems to find the set of UID/GIDs currently referenced, and remove entries from the historical mappings that are no longer needed. What do you think? Mark From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 16:05:49 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 20:05:49 +0000 Received: from localhost ([127.0.0.1]:39313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX8FI-00071p-KT for submit@debbugs.gnu.org; Thu, 15 Apr 2021 16:05:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX8FG-00071a-2R for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 16:05:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43756) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lX8FA-0006fw-8H; Thu, 15 Apr 2021 16:05:40 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=38568 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lX8F8-0006Z9-Qx; Thu, 15 Apr 2021 16:05:39 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Mark H Weaver Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87lf9jiems.fsf@netris.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 26 Germinal an 229 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 15 Apr 2021 22:05:36 +0200 In-Reply-To: <87lf9jiems.fsf@netris.org> (Mark H. Weaver's message of "Thu, 15 Apr 2021 14:30:40 -0400") Message-ID: <878s5j8ga7.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Mark, Mark H Weaver skribis: > Ludovic Court=C3=A8s writes: > >> Note that there are other places, in addition to GDM, where we >> forcefully reset the UID/GID of the home directory (e.g., for the >> =E2=80=98knot-resolver=E2=80=99 service.) >> >> My preferred solution to this would be to unconditionally chown -R home >> directories upon activation (for efficiency, it would be best if we >> could do that if and only if the home directory itself has wrong >> ownership). Thoughts? > > It might be okay to do this in specific cases like /var/lib/gdm, but I'm > very uncomfortable doing it for *all* users, because: > > (1) We shouldn't assume that all files within a home directory are > supposed to be owned by that user. > > (2) We shouldn't assume that all files owned by a user will be within > their home directory. > > (3) We shouldn't assume that all files within a home directory are > supposed to have the same 'group'. I, for one, have sometimes had > subdirectories of my home directory with a different 'group', to > either restrict or grant other users access to selected files or > directories. > > (4) Groups do not, in general, have home directories. > > (5) I consider it unsatifactory for there to be *any* window of time > during system activation when the ownership of files is incorrect. I agree this raises questions and we should take time to think through it. For system accounts though, I think 1=E2=80=934 do not apply. Perhaps a first step would be to do that for system accounts? >> Note that the ID allocation strategy in (gnu build accounts) ensures >> UIDs/GIDs aren=E2=80=99t reused right away (same strategy as implemented= by >> Shadow, etc.). So if you remove =E2=80=9Cbob=E2=80=9D, then add =E2=80= =9Calice=E2=80=9D, =E2=80=9Calice=E2=80=9D won=E2=80=99t >> be able to access the left-behind /home/bob because it has a different >> UID. To be clear, it=E2=80=99s doing the same as any other GNU/Linux distro. > This mechanism is insufficient, because it only avoids the problem if > you add "alice" at the same time that "bob" is removed. If you remove > "bob" during one system activation, and then later add "alice", then > "alice" might well be able to access bob's left-behind files. > > In the case that I personally witnessed on my Guix system, files within > /var/lib/gdm ended up with 'colord' as their group. That's not good. > > Increasingly, I'm leaning toward the idea that the complete mapping from > names to IDs should somehow be explicitly given as part of the OS > configuration, as I advocated in . > > What do you think? IDs as hash of the user names are interesting because that=E2=80=99d be stateless (conversely, the current ID allocation strategy is stateful: it arranges to not reuse recently-freed IDs.) But like you write, we=E2=80=99d need 32-bit UIDs. In libc, =E2=80=98uid_t= =E2=80=99 (specifically =E2=80=98__UID_T_TYPE=E2=80=99 in typesizes.h) is 32-bit, so = it might work rather well in user space. It still sounds like a change with significant implications though, and it=E2=80=99s hard to predict exactly how it would go or what would break. = For example, that does away with the system/non-system ranges, and wouldn=E2=80= =99t play well with =E2=80=9Cspecial=E2=80=9D IDs like 0 and 65535. To me, it=E2=80=99s a potential way out, but not a solution for the bug Bre= ndan reported today, nor a change we could implement in the coming weeks/months; the time scale is probably longer. WDYT? Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 18:24:42 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 22:24:42 +0000 Received: from localhost ([127.0.0.1]:39465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXAPi-00041I-Dq for submit@debbugs.gnu.org; Thu, 15 Apr 2021 18:24:42 -0400 Received: from world.peace.net ([64.112.178.59]:41266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXAPh-000415-5E for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 18:24:41 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXAPa-00085V-0Y; Thu, 15 Apr 2021 18:24:34 -0400 From: Mark H Weaver To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <878s5j8ga7.fsf@gnu.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87lf9jiems.fsf@netris.org> <878s5j8ga7.fsf@gnu.org> Date: Thu, 15 Apr 2021 18:22:49 -0400 Message-ID: <87zgxzgpbf.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludovic, Ludovic Court=C3=A8s wrote: >>> Note that the ID allocation strategy in (gnu build accounts) ensures >>> UIDs/GIDs aren=E2=80=99t reused right away (same strategy as implemente= d by >>> Shadow, etc.). So if you remove =E2=80=9Cbob=E2=80=9D, then add =E2=80= =9Calice=E2=80=9D, =E2=80=9Calice=E2=80=9D won=E2=80=99t >>> be able to access the left-behind /home/bob because it has a different >>> UID. I replied: >> This mechanism is insufficient, because it only avoids the problem if >> you add "alice" at the same time that "bob" is removed. If you remove >> "bob" during one system activation, and then later add "alice", then >> "alice" might well be able to access bob's left-behind files. Ludovic Court=C3=A8s responded: > To be clear, it=E2=80=99s doing the same as any other GNU/Linux distro. I don't think that's quite right. It's true that if you delete a user or group on another distro and then re-add it, it might not be assigned the same UID/GID. That much is the same as any other distro. The key difference is this: On Debian, at least in my experience, users and groups are *never* deleted automatically. They are only added automatically, but never removed unless you explicitly ask to remove them. So, this problem does not arise in practice. Thanks, Mark From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 19:06:24 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 23:06:24 +0000 Received: from localhost ([127.0.0.1]:39523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXB44-000525-MT for submit@debbugs.gnu.org; Thu, 15 Apr 2021 19:06:24 -0400 Received: from world.peace.net ([64.112.178.59]:41330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXB41-00051o-38 for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 19:06:24 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXB3u-0002Zm-Ox; Thu, 15 Apr 2021 19:06:14 -0400 From: Mark H Weaver To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <878s5j8ga7.fsf@gnu.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87lf9jiems.fsf@netris.org> <878s5j8ga7.fsf@gnu.org> Date: Thu, 15 Apr 2021 19:04:30 -0400 Message-ID: <87wnt3gndy.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludovic, Ludovic Court=C3=A8s writes: > IDs as hash of the user names are interesting because that=E2=80=99d be > stateless (conversely, the current ID allocation strategy is stateful: > it arranges to not reuse recently-freed IDs.) > > But like you write, we=E2=80=99d need 32-bit UIDs. In libc, =E2=80=98uid= _t=E2=80=99 > (specifically =E2=80=98__UID_T_TYPE=E2=80=99 in typesizes.h) is 32-bit, s= o it might work > rather well in user space. The kernel and core system components certainly support 32-bit UIDs, and have for around 20 years. > It still sounds like a change with significant implications though, and > it=E2=80=99s hard to predict exactly how it would go or what would break. Right, my concern is with the vast majority of programs and libraries in Guix, most of which probably haven't seen much (if any) testing with large UIDs. > For example, that does away with the system/non-system ranges, and > wouldn=E2=80=99t play well with =E2=80=9Cspecial=E2=80=9D IDs like 0 and = 65535. This particular issue is easily addressed. It's easy enough to find a function from 31-hash values to 32-bit IDs that's injective and avoids any chosen subset of special IDs, as long as there are fewer than 2^31 special IDs. Simply adding 65536 (or even 2^31) to the hash value would be one easy option. What do you think? Mark From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 16 06:43:14 2021 Received: (at 36508) by debbugs.gnu.org; 16 Apr 2021 10:43:14 +0000 Received: from localhost ([127.0.0.1]:40105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXLwQ-0001KR-5C for submit@debbugs.gnu.org; Fri, 16 Apr 2021 06:43:14 -0400 Received: from xavier.telenet-ops.be ([195.130.132.52]:33434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXLwM-0001KG-Ni for 36508@debbugs.gnu.org; Fri, 16 Apr 2021 06:43:12 -0400 Received: from ptr-bvsjgyjmffd7q9timvx.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:aaf1:9810:a0b8:a55d]) by xavier.telenet-ops.be with bizsmtp id tNj82400K0mfAB401Nj8Un; Fri, 16 Apr 2021 12:43:09 +0200 Message-ID: <38fd9bfdc71c689df1606a0b00d632e423c5defa.camel@telenet.be> Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service From: Maxime Devos To: Mark H Weaver , Ludovic =?ISO-8859-1?Q?Court=E8s?= Date: Fri, 16 Apr 2021 12:42:53 +0200 In-Reply-To: <87eefbidcs.fsf@netris.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87eefbidcs.fsf@netris.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-vI66qH0XHOizTwd9LNSk" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1618569789; bh=6fK+zfjLWh0vsbQPCEOwSVJVNlEj7zV+JoyaknT3oFU=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ODBkCkzDv+orOTIP6prKoFg+po0S5xknwhiv2Sm66HF1UrE+6lCEvlHwjdLZeEWEa 8Hav+/J0O1WtL5+wjRESNwhnNbUy1/ofQWR07cBpwIHyuChXBCRSEltID+M4OCGb/2 LPas723h5PDHNTqrsZzTjfnhtslRCihz6J4QI9rdPGUmFFiUs/ByEEEfMpGaUlMb5m y8z+jVcNaCMxYoLxG0nxYrJUwb2QVVQCIU56qjoQvOnCO5YSvJuQDIEkS60gI4AP90 cepgikjhWukKQkbTwNI+sdw15oDBnpeZKPMaiZ4Ci/wZX/QV6urJeqBDkOOr9fHOZM mhwGWvj9QNGJg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-vI66qH0XHOizTwd9LNSk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2021-04-15 at 14:58 -0400, Mark H Weaver wrote: > Ludovic Court=C3=A8s writes: >=20 > > Mark H Weaver skribis: > >=20 > > > Here's one idea: when activating a system, *never* delete users or > > > groups if files still exist that are owned by those users/groups. > > > Checking all filesystems would likely be too expensive, but perhaps i= t > > > would be sufficient to check certain directories such as /var, /etc, = and > > > possibly the top directory of /home. And /tmp, /media and /run/user. > >=20 > > How would you determine which directories to look at though? What if w= e > > miss an important one? >=20 > I have another idea: >=20 > Maintain historical mappings from user/group names to UIDs/GIDs, perhaps > in some file in /etc, where entries are added but *never* automatically > removed. When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the > range of those mappings. This seems rather convoluted to me. Why not reuse /etc/passwd and /etc/gro= ups? My suggestion: 1. *never* automatically delete users/groups from /etc/passwd, /etc/groups (I thought that was how Guix already worked ...) 2. as users and groups appearing in /etc/passwd and /etc/groups, but not in the operating system configuration can be confusing, change the comme= nt string of these users and groups, to something like "account removed" Add a group 'user-graveyard' for (3), and move these 'pseudo-removed' us= ers to the 'user-graveyard' group. 3. Don't forget to remove graveyard users from all groups (except user-grav= eyard), make sure the graveyard users can't log in anymore ... (Perhaps add a ru= le to the SSH and PAM configuration that forbids logging in to graveyard accou= nts, by checking whether the user is in the 'user-graveyard' group?) > Then, provide a UID/GID garbage collector, to be explicitly run by users > if desired, which would scan all filesystems to find the set of UID/GIDs > currently referenced, and remove entries from the historical mappings > that are no longer needed. That seems useful for if /etc/passwd and /etc/group is getting full, or jus= t for cleaning up. You may want to exclude /gnu/store though, for efficiency (-:= . And just in case check whether any live processes have the UID/GID. Suggested command name: "guix user-gc". Greetings, Maxime. --=-vI66qH0XHOizTwd9LNSk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYHlqLRccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7iLeAQCDp8ywXTcQrPOsnQ427HUGcXmo W23thxgqzXqSPwy5ZAD9EoGaIgOLrMymibzhCeJ/alf6nGRxQjonoxZ9cyuq5A0= =Ht7l -----END PGP SIGNATURE----- --=-vI66qH0XHOizTwd9LNSk-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 16 11:14:22 2021 Received: (at 36508) by debbugs.gnu.org; 16 Apr 2021 15:14:22 +0000 Received: from localhost ([127.0.0.1]:41424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXQAo-0001yA-8f for submit@debbugs.gnu.org; Fri, 16 Apr 2021 11:14:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXQAm-0001xr-Jr for 36508@debbugs.gnu.org; Fri, 16 Apr 2021 11:14:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41997) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXQAg-0000WS-EO; Fri, 16 Apr 2021 11:14:14 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=39090 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lXQAf-0001de-W1; Fri, 16 Apr 2021 11:14:14 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Mark H Weaver Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87lf9jiems.fsf@netris.org> <878s5j8ga7.fsf@gnu.org> <87wnt3gndy.fsf@netris.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 27 Germinal an 229 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Fri, 16 Apr 2021 17:14:11 +0200 In-Reply-To: <87wnt3gndy.fsf@netris.org> (Mark H. Weaver's message of "Thu, 15 Apr 2021 19:04:30 -0400") Message-ID: <871rba5kjg.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Mark, Mark H Weaver skribis: > This particular issue is easily addressed. It's easy enough to find a > function from 31-hash values to 32-bit IDs that's injective and avoids > any chosen subset of special IDs, as long as there are fewer than 2^31 > special IDs. > > Simply adding 65536 (or even 2^31) to the hash value would be one easy > option. > > What do you think? Yes, but these special IDs are just examples of things that could go wrong. I don=E2=80=99t know, maybe I=E2=80=99m just overly cautious; we ha= ve to try to get a better understanding of how things will go! Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 16 11:18:16 2021 Received: (at 36508) by debbugs.gnu.org; 16 Apr 2021 15:18:16 +0000 Received: from localhost ([127.0.0.1]:41435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXQEZ-00024o-PQ for submit@debbugs.gnu.org; Fri, 16 Apr 2021 11:18:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXQEX-00024b-Mn for 36508@debbugs.gnu.org; Fri, 16 Apr 2021 11:18:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42068) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXQES-0002Dg-HG; Fri, 16 Apr 2021 11:18:08 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=39092 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lXQES-0001y5-23; Fri, 16 Apr 2021 11:18:08 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Mark H Weaver Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87lf9jiems.fsf@netris.org> <878s5j8ga7.fsf@gnu.org> <87zgxzgpbf.fsf@netris.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 27 Germinal an 229 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Fri, 16 Apr 2021 17:18:06 +0200 In-Reply-To: <87zgxzgpbf.fsf@netris.org> (Mark H. Weaver's message of "Thu, 15 Apr 2021 18:22:49 -0400") Message-ID: <87tuo645sh.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi, Mark H Weaver skribis: > It's true that if you delete a user or group on another distro and then > re-add it, it might not be assigned the same UID/GID. That much is the > same as any other distro. > > The key difference is this: On Debian, at least in my experience, users > and groups are *never* deleted automatically. They are only added > automatically, but never removed unless you explicitly ask to remove > them. So, this problem does not arise in practice. >> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps >> in some file in /etc, where entries are added but *never* automatically >> removed. When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the >> range of those mappings. If we=E2=80=99re just worried about ID allocation, we could keep state in, = say, /etc/previous-uids, and feed that as input to the (gnu build accounts) allocation code. Thoughts? Maxime Devos skribis: > This seems rather convoluted to me. Why not reuse /etc/passwd and /etc/g= roups? > My suggestion: > > 1. *never* automatically delete users/groups from /etc/passwd, /etc/groups > (I thought that was how Guix already worked ...) > 2. as users and groups appearing in /etc/passwd and /etc/groups, but not > in the operating system configuration can be confusing, change the com= ment > string of these users and groups, to something like > > "account removed" > > Add a group 'user-graveyard' for (3), and move these 'pseudo-removed' = users > to the 'user-graveyard' group. > 3. Don't forget to remove graveyard users from all groups (except user-gr= aveyard), > make sure the graveyard users can't log in anymore ... (Perhaps add a = rule to > the SSH and PAM configuration that forbids logging in to graveyard acc= ounts, > by checking whether the user is in the 'user-graveyard' group?) Problem is that things like GDM would still propose those old accounts (unless maybe their password is uninitialized, I=E2=80=99m not sure; but it= =E2=80=99s still hacky.) Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 17 12:18:42 2021 Received: (at 36508) by debbugs.gnu.org; 17 Apr 2021 16:18:42 +0000 Received: from localhost ([127.0.0.1]:44212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXneb-0004Is-Oe for submit@debbugs.gnu.org; Sat, 17 Apr 2021 12:18:41 -0400 Received: from world.peace.net ([64.112.178.59]:45424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXnea-0004If-6i for 36508@debbugs.gnu.org; Sat, 17 Apr 2021 12:18:40 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXneT-0003aW-22; Sat, 17 Apr 2021 12:18:33 -0400 From: Mark H Weaver To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <87tuo645sh.fsf@gnu.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87lf9jiems.fsf@netris.org> <878s5j8ga7.fsf@gnu.org> <87zgxzgpbf.fsf@netris.org> <87tuo645sh.fsf@gnu.org> Date: Sat, 17 Apr 2021 12:16:43 -0400 Message-ID: <87blac9989.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludovic, Ludovic Court=C3=A8s writes: > Mark H Weaver skribis: > >>> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps >>> in some file in /etc, where entries are added but *never* automatically >>> removed. When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the >>> range of those mappings. > > If we=E2=80=99re just worried about ID allocation, we could keep state in= , say, > /etc/previous-uids, and feed that as input to the (gnu build accounts) > allocation code. Sounds good to me, or at least better than the other available options. Thanks, Mark From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 17 12:30:09 2021 Received: (at 36508) by debbugs.gnu.org; 17 Apr 2021 16:30:09 +0000 Received: from localhost ([127.0.0.1]:44230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXnpg-0004bH-OT for submit@debbugs.gnu.org; Sat, 17 Apr 2021 12:30:09 -0400 Received: from world.peace.net ([64.112.178.59]:45450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXnpe-0004ZN-OH for 36508@debbugs.gnu.org; Sat, 17 Apr 2021 12:30:07 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXnpX-0004Pf-NV; Sat, 17 Apr 2021 12:29:59 -0400 From: Mark H Weaver To: Maxime Devos , Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <38fd9bfdc71c689df1606a0b00d632e423c5defa.camel@telenet.be> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87eefbidcs.fsf@netris.org> <38fd9bfdc71c689df1606a0b00d632e423c5defa.camel@telenet.be> Date: Sat, 17 Apr 2021 12:28:10 -0400 Message-ID: <878s5g98p6.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Maxime, Maxime Devos writes: > On Thu, 2021-04-15 at 14:58 -0400, Mark H Weaver wrote: >> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps >> in some file in /etc, where entries are added but *never* automatically >> removed. When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the >> range of those mappings. > > This seems rather convoluted to me. Why not reuse /etc/passwd and /etc/groups? > My suggestion: > > 1. *never* automatically delete users/groups from /etc/passwd, /etc/groups > (I thought that was how Guix already worked ...) > 2. as users and groups appearing in /etc/passwd and /etc/groups, but not > in the operating system configuration can be confusing, change the comment > string of these users and groups, to something like > > "account removed" > > Add a group 'user-graveyard' for (3), and move these 'pseudo-removed' users > to the 'user-graveyard' group. > 3. Don't forget to remove graveyard users from all groups (except user-graveyard), > make sure the graveyard users can't log in anymore ... (Perhaps add a rule to > the SSH and PAM configuration that forbids logging in to graveyard accounts, > by checking whether the user is in the 'user-graveyard' group?) I would be okay with this approach as well, although it's not obvious to me that it's any cleaner than having a separate /etc/previous-uids file, given items 2 and 3 above. >> Then, provide a UID/GID garbage collector, to be explicitly run by users >> if desired, which would scan all filesystems to find the set of UID/GIDs >> currently referenced, and remove entries from the historical mappings >> that are no longer needed. > > That seems useful for if /etc/passwd and /etc/group is getting full, or just for > cleaning up. You may want to exclude /gnu/store though, for efficiency (-:. Good point! That's one directory that would clearly be a waste to scan :-) > And just in case check whether any live processes have the UID/GID. Sure, sounds good. Thanks! Mark From debbugs-submit-bounces@debbugs.gnu.org Sun May 09 12:46:38 2021 Received: (at control) by debbugs.gnu.org; 9 May 2021 16:46:38 +0000 Received: from localhost ([127.0.0.1]:56235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lfmZh-0002tp-N2 for submit@debbugs.gnu.org; Sun, 09 May 2021 12:46:37 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:37733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lfmZd-0002mT-Rt for control@debbugs.gnu.org; Sun, 09 May 2021 12:46:36 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8E6EC5C0105; Sun, 9 May 2021 12:46:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 09 May 2021 12:46:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name; h=date:from:to:message-id:mime-version:content-type; s=mesmtp; bh=pHwQJcL0KvdJxA01VAqnRMrhWC7faDuhQJHA4sjMXu0=; b=VrFjlSPmDLQA XEg4UvsBkibB4mAO3nRQJhqOsMZUNq+32PblO/YwBVVDUDfeYwoxqdaIPNt8vzTP C/wMNeHy1otYyW3NOTTrhv1Xrw8jbpmpiAVGFpMjk1wPM/jQEgJsVKcE4BtrxDvD cbfASJfzG5h4crFQQRL0zwHm5I+jfBI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=pHwQJcL0KvdJxA01VAqnRMrhWC7faDuhQJHA4sjMX u0=; b=oz/l7h4KGyXBrmp+fG0jTsPK5T7+r+bPNUEoGJJ+uemEEA5Zi3Rd9+3Vq j4wpu+MKEuLzn8wgp4gyS1qIOFIzp2ji7ePMtKQ5ha10r2l0+lryPIsd9jarSXVV ovm1mkQBimGpeyojHhW+9jDiyQ2AMgO+gg1omjejPq3FJb4ISUapN/ilTkhhEQl1 JQ0qxGhbI9kW6BKD6FE6rYSZRREHejy5hzfNerIOc+b0oTvVYZBmkJcWrehhKkdt xogROUqGSjSrGQ69O1aIEYHMGm6CbWgFCN+kAqVw0yYwAuuEg6KZfwuG++/DD2IV bWaeoDka5GIEQlrGIWA96GafpmB9w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdegiedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecugfhmphhthicushhusghjvggtthculddutddmne cujfgurhepfffhvffkgggtugesthdtredttddtvdenucfhrhhomhepnfgvohcuhfgrmhhu lhgrrhhiuceolhgvohesfhgrmhhulhgrrhhirdhnrghmvgeqnecuggftrfgrthhtvghrnh ephfejiefgfeevvdefteehgeeltdekvedutdegtdduieetheetgedvfeffudfffeffnecu kfhppedutddtrdduuddrudeiledruddukeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehlvghosehfrghmuhhlrghrihdrnhgrmhgv X-ME-Proxy: Received: from localhost (pool-100-11-169-118.phlapa.fios.verizon.net [100.11.169.118]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 9 May 2021 12:46:28 -0400 (EDT) Date: Sun, 9 May 2021 12:46:26 -0400 From: Leo Famulari To: control@debbugs.gnu.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: merge 39527 36508 Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [66.111.4.26 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [66.111.4.26 listed in wl.mailspike.net] 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) merge 39527 36508 From debbugs-submit-bounces@debbugs.gnu.org Sun May 09 12:51:38 2021 Received: (at control) by debbugs.gnu.org; 9 May 2021 16:51:38 +0000 Received: from localhost ([127.0.0.1]:56264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lfmeY-0003iU-OC for submit@debbugs.gnu.org; Sun, 09 May 2021 12:51:38 -0400 Received: from mout-p-101.mailbox.org ([80.241.56.151]:58298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lfmeX-0003iO-Dw for control@debbugs.gnu.org; Sun, 09 May 2021 12:51:37 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4FdVZW2CVwzQjxR for ; Sun, 9 May 2021 18:51:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brendan.scot; s=MBO0001; t=1620579089; h=from:from:reply-to:subject:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=pHwQJcL0KvdJxA01VAqnRMrhWC7faDuhQJHA4sjMXu0=; b=kHYJEEp5Gr2g/+MQJBUJLk1WqjU1jYeh9jGwSkG+hi9m/iUbh9XCK4kPhTZicFjuSEhcA3 /vaGLlcdoWHVPrJqsxVu0pGZCJJTi5ztcAAKjSzx5kvwh/p4pvzTdaHX1yiACk0gp4nni/ UyzXgB9Y5aK+e+i7fvaNERdpYICKHg92VSIf70BYQ2ToYRyDct6TBTxS2OyoFrXQ3ZphJ7 ADRJK+JXLvyaFjPlcvvyl4xLP4dpVkwVJhXj0LFov29T3cVNFZv6HynNwU+wLdeWN2QEZK NCfTWUACiDfKClDi7HE2lg0EdFTI+8nhY5E8tUUxq862pFYNnLr59VlIMBcWOw== Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id uugWwzEq1CI4 for ; Sun, 9 May 2021 18:51:28 +0200 (CEST) To: control@debbugs.gnu.org From: Brendan Tildesley Message-ID: Date: Mon, 10 May 2021 02:51:24 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-MBO-SPAM-Probability: * X-Rspamd-Score: 0.19 / 15.00 / 15.00 X-Rspamd-Queue-Id: 7431D17BE X-Rspamd-UID: c39069 X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: merge 39527 36508 Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [80.241.56.151 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) merge 39527 36508 From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 18 08:22:43 2022 Received: (at 36508) by debbugs.gnu.org; 18 Sep 2022 12:22:43 +0000 Received: from localhost ([127.0.0.1]:48213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZtJq-00081h-4h for submit@debbugs.gnu.org; Sun, 18 Sep 2022 08:22:43 -0400 Received: from xavier.telenet-ops.be ([195.130.132.52]:49106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZtJn-00081X-Pc for 36508@debbugs.gnu.org; Sun, 18 Sep 2022 08:22:41 -0400 Received: from [192.168.81.79] ([188.188.37.253]) by xavier.telenet-ops.be with bizsmtp id MQNc280075TiYSc01QNcow; Sun, 18 Sep 2022 14:22:38 +0200 Message-ID: <020888b6-6e8d-23d8-ee81-92884c717fbe@telenet.be> Date: Sun, 18 Sep 2022 14:22:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US To: 36508@debbugs.gnu.org From: Maxime Devos Subject: [DRAFT PATCH] Stable allocation of uids, by keeping a historical mapping. Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------HpdMtMHClxb1SVem0RL9QZMu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1663503758; bh=9TV0DR7vDjj9J+zcn/xD2s1nX1UgoT9IC/6FYV+4E00=; h=Date:To:From:Subject; b=OOqaXoTJ0UoSZ1r3q9bgVQXnvNk/u7bShXkOwNXSfW40eGx0Q6aM2Ig7FHhgW4vYG eGGNcf126rekOz4ei5CN5tYNxYxFSr8IVA5qq8GMN5WXcWpOlWhTrYzRtVBZNgqwJz 1EKnGSSEgbIkOZmKrSEOPwpClu/nHtei5d7Ku5VzoQtGjUYGs8VsbRtRYA5ef55qSc WVQ9B7giQ0D9yBRZHW8ENLiRAaH4dW4QuEDzQjYE3ahRZkbzvuSlCKlMqtVOCEcKZv D9CIangCl+X/IJxD4syUOka4kAUWjOfLavqC0kA3LOCj9WHu+Kb148SH0jtGXt91EF LFv4kwqU7M9lQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 36508 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------HpdMtMHClxb1SVem0RL9QZMu Content-Type: multipart/mixed; boundary="------------5TFhG3tH0dVn3brDeQ29Kal4"; protected-headers="v1" From: Maxime Devos To: 36508@debbugs.gnu.org Message-ID: <020888b6-6e8d-23d8-ee81-92884c717fbe@telenet.be> Subject: [DRAFT PATCH] Stable allocation of uids, by keeping a historical mapping. --------------5TFhG3tH0dVn3brDeQ29Kal4 Content-Type: multipart/mixed; boundary="------------n0aORaGnf7ZoTpwNBOcR47qk" --------------n0aORaGnf7ZoTpwNBOcR47qk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGksDQoNClRoZSBhdHRhY2hlZCBwYXRjaCBtYWludGFpbnMgYSBoaXN0b3JpY2FsIG1hcHBp bmcgZnJvbSB1c2VyIG5hbWVzIHRvIA0KVUlEcy9HSURzIChldmVuIHdoZW4gdGhvc2UgdXNl cnMgYXJlIHJlbW92ZWQgZnJvbSB0aGUgdXNlciBhY2NvdW50cyksIHRvIA0Kc29sdmUgPGh0 dHBzOi8vaXNzdWVzLmd1aXguZ251Lm9yZy8zNjUwOD4sIGFzIHByb3Bvc2VkIGJ5IE1hcmsg SCBXZWF2ZXIgDQppbiA8aHR0cHM6Ly9pc3N1ZXMuZ3VpeC5nbnUub3JnLzM2NTA4IzEwPi4N Cg0KKFRoZSBwcm9wb3NlZCBnYXJiYWdlIGNvbGxlY3RvciBpcyBub3QgaW5jbHVkZWQsIGhv d2V2ZXIuKQ0KDQpBcyBJIHByb3Bvc2VkIGluIDxodHRwczovL2lzc3Vlcy5ndWl4LmdudS5v cmcvMzY1MDgjMTQ+LCB0aGUgaW5mb3JtYXRpb24gDQpvZiB0aGlzIG1hcHBpbmcgaXMga2Vw dCBpbiBhIHNwZWNpYWwgJ3VzZXInLiAgSG93ZXZlciwgSSBkaWRuJ3QgDQppbXBsZW1lbnQg dGhlIHNhbWUgZm9yIGdyb3VwcyAocmFpc2VzIHNvbWUgcXVlc3Rpb25zIGFib3V0IGF0b21p Y2l0eSAtLSANCi9ldGMvcGFzc3dkIGFuZCAvZXRjL2dyb3VwcyBhcmUgc2VwYXJhdGUgZmls ZXMpLg0KDQpJIGRpZG4ndCBjb21wbGV0ZWx5IGZvbGxvdyB0aGF0IHByb3Bvc2FsIHRob3Vn aCwgc2luY2U6DQoNCiA+IGh0dHBzOi8vaXNzdWVzLmd1aXguZ251Lm9yZy8zNjUwOCMxNjoN CiA+IFByb2JsZW0gaXMgdGhhdCB0aGluZ3MgbGlrZSBHRE0gd291bGQgc3RpbGwgcHJvcG9z ZSB0aG9zZSBvbGQgYWNjb3VudHMNCiA+ICh1bmxlc3MgbWF5YmUgdGhlaXIgcGFzc3dvcmQg aXMgdW5pbml0aWFsaXplZCwgSeKAmW0gbm90IHN1cmU7IGJ1dCBpdOKAmXMNCiA+IHN0aWxs IGhhY2t5LikNCg0KLCB0aG91Z2ggdGhhdCBjb3VsZCBwZXJoYXBzIGJlIHNvbHZlZCBieSBh ZGp1c3RpbmcgR0RNIGFwcHJvcHJpYXRlbHkuDQoNCiJtYWtlIGNoZWNrIFRFU1RTPXRlc3Rz L2FjY291bnRzLnNjbSIgcGFzc2VzLCBidXQgb3RoZXJ3aXNlIHRoZSBwYXRjaCBpcyANCnJh dGhlciB1bnRlc3RlZCAoaGVuY2UsICdEUkFGVCcpIC0tIHRoZSBuZXcgZnVuY3Rpb25hbGl0 eSB3aWxsIG5lZWQgYSANCmZldyBhZGRpdGlvbmFsIHRlc3RzIGluIHRlc3RzL2FjY291bnQu c2NtLCB0byBhdm9pZCBpbnRyb2R1Y2luZyBidWdzIGluIA0KdGhlIGhhbmRsaW5nIG9mIC9l dGMvcGFzc3dkLg0KDQpPbiBzZWNvbmQgdGhvdWdodCwgYSBzZXBhcmF0ZSAvZXRjL3ByZXZp b3VzLXVpZHMgKGFzIHByb3Bvc2VkIGluDQo8aHR0cHM6Ly9pc3N1ZXMuZ3VpeC5nbnUub3Jn LzM2NTA4IzE2PiBieSBMdWRvdmljIENvdXJ0w6hzKQ0KbWlnaHQgYmUgYmV0dGVyICh0aGVy ZSBhcmUgYXRvbWljaXR5IGlzc3VlcyBhbnl3YXksIGR1ZSB0byAvZXRjL3Bhc3N3ZCANCmFu ZCAvZXRjL2dyb3VwcyBiZWluZyBzZXBhcmF0ZSBmaWxlcywgYW5kIGxvc2luZyB0aGUgaGlz dG9yaWNhbCBtYXBwaW5nDQppcyByZWxhdGl2ZWx5IGhhcm1sZXNzIGFuZCBzZWVtcyB1bmxp a2VseSB0byBoYXBwZW4gaW4gcHJhY3RpY2UpLg0KDQpHcmVldGluZ3MsDQpNYXhpbWUNCg== --------------n0aORaGnf7ZoTpwNBOcR47qk Content-Type: text/x-patch; charset=UTF-8; name="0001-DRAFT-Stable-allocation-of-uids.patch" Content-Disposition: attachment; filename="0001-DRAFT-Stable-allocation-of-uids.patch" Content-Transfer-Encoding: base64 RnJvbSAxZTBlYjc4ZmI3YWUxYTdiNmM0MGUzNjRkODhiMGIzMzk0NWVmN2MxIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBNYXhpbWUgRGV2b3MgPG1heGltZWRldm9zQHRlbGVu ZXQuYmU+CkRhdGU6IFN1biwgMTggU2VwIDIwMjIgMTQ6MTg6MTAgKzAyMDAKU3ViamVjdDog W1BBVENIXSBEUkFGVDogU3RhYmxlIGFsbG9jYXRpb24gb2YgdWlkcwoKLS0tCiBnbnUvYnVp bGQvYWNjb3VudHMuc2NtIHwgMTg2ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrLS0tLS0tCiB0ZXN0cy9hY2NvdW50cy5zY20gICAgIHwgIDE0ICsrKy0KIDIgZmlsZXMg Y2hhbmdlZCwgMTczIGluc2VydGlvbnMoKyksIDI3IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp dCBhL2dudS9idWlsZC9hY2NvdW50cy5zY20gYi9nbnUvYnVpbGQvYWNjb3VudHMuc2NtCmlu ZGV4IDEyNDdmYzY0MGMuLjVlMDRlOWY1MjYgMTAwNjQ0Ci0tLSBhL2dudS9idWlsZC9hY2Nv dW50cy5zY20KKysrIGIvZ251L2J1aWxkL2FjY291bnRzLnNjbQpAQCAtMSw1ICsxLDYgQEAK IDs7OyBHTlUgR3VpeCAtLS0gRnVuY3Rpb25hbCBwYWNrYWdlIG1hbmFnZW1lbnQgZm9yIEdO VQogOzs7IENvcHlyaWdodCDCqSAyMDE5LCAyMDIxIEx1ZG92aWMgQ291cnTDqHMgPGx1ZG9A Z251Lm9yZz4KKzs7OyBDb3B5cmlnaHQgwqkgMjAyMiBNYXhpbWUgRGV2b3MgPG1heGltZWRl dm9zQHRlbGVuZXQuYmU+CiA7OzsKIDs7OyBUaGlzIGZpbGUgaXMgcGFydCBvZiBHTlUgR3Vp eC4KIDs7OwpAQCAtMTcsOSArMTgsMTEgQEAKIDs7OyBhbG9uZyB3aXRoIEdOVSBHdWl4LiAg SWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9yZy9saWNlbnNlcy8+LgogCiAoZGVmaW5l LW1vZHVsZSAoZ251IGJ1aWxkIGFjY291bnRzKQorICAjOnVzZS1tb2R1bGUgKGd1aXggYmFz ZTY0KQogICAjOnVzZS1tb2R1bGUgKGd1aXggcmVjb3JkcykKICAgIzp1c2UtbW9kdWxlIChn dWl4IGNvbWJpbmF0b3JzKQogICAjOnVzZS1tb2R1bGUgKGdudSBzeXN0ZW0gYWNjb3VudHMp CisgICM6dXNlLW1vZHVsZSAocm5ycyBieXRldmVjdG9ycykKICAgIzp1c2UtbW9kdWxlIChz cmZpIHNyZmktMSkKICAgIzp1c2UtbW9kdWxlIChzcmZpIHNyZmktMTEpCiAgICM6dXNlLW1v ZHVsZSAoc3JmaSBzcmZpLTE5KQpAQCAtNzIsMTAgKzc1LDE2IEBAIChkZWZpbmUtbW9kdWxl IChnbnUgYnVpbGQgYWNjb3VudHMpCiA7OzsgPHNoYWRvdy5oPiwgPHB3ZC5oPiwgYW5kIDxn cnAuaD4gcm91dGluZXMsIGFzIHdlbGwgYXMgYSBzdWJzZXQgb2YgdGhlCiA7OzsgZnVuY3Rp b25hbGl0eSBvZiB0aGUgU2hhZG93IGNvbW1hbmQtbGluZSB0b29scy4gIEl0IGNhbiBwYXJz ZSBhbmQgd3JpdGUKIDs7OyAvZXRjL3Bhc3N3ZCwgL2V0Yy9zaGFkb3csIGFuZCAvZXRjL2dy b3VwLiAgSXQgY2FuIGFsc28gdGFrZSBjYXJlIG9mIFVJRAotOzs7IGFuZCBHSUQgYWxsb2Nh dGlvbiBpbiBhIHdheSBzaW1pbGFyIHRvIHdoYXQgJ3VzZXJhZGQnIGRvZXMuCis7OzsgYW5k IEdJRCBhbGxvY2F0aW9uLCBpbiBhIGRpZmZlcmVudCB3YXkgdGhhbiAndXNlcmFkZCcgZG9l cy4KIDs7OwotOzs7IFRoZSBiZW5lZml0IGlzIHR3b2ZvbGQ6IGxlc3MgY29kZSBpcyBpbnZv bHZlZCwgYW5kIHRoZSBJRCBhbGxvY2F0aW9uCi07Ozsgc3RyYXRlZ3kgYW5kIHN0YXRlIHBy ZXNlcnZhdGlvbiBpcyBtYWRlIGV4cGxpY2l0LgorOzs7IFRoZSBiZW5lZml0IGlzIHRocmVl Zm9sZDogbGVzcyBjb2RlIGlzIGludm9sdmVkLCB0aGUgSUQgYWxsb2NhdGlvbgorOzs7IHN0 cmF0ZWd5IGFuZCBzdGF0ZSBwcmVzZXJ2YXRpb24gaXMgbWFkZSBleHBsaWNpdCBhbmQgaXQg YXZvaWRzCis7OzsgYWxsb2NhdGluZyBJRHMgdGhhdCB3ZXJlIGluIHRoZSBwYXN0IGFsbG9j YXRlZCBmb3Igc29tZSB1c2VyIHVzZXIKKzs7OyBhbmQgcmVtb3ZlZCBidXQgc3RpbGwgcHJl c2VudCBzb21ld2hlcmUgaW4gdGhlIGZpbGUgc3lzdGVtLgorOzs7IEFkZGl0aW9uYWxseSwg d2hlbiBzdWNoIGFuIHVzZXIgaXMgcmUtYWRkZWQsIEd1aXggd2lsbCB1c2UgdGhlIHNhbWUK Kzs7OyBJRCBhZ2FpbgorOzs7Cis7OzsgVE9ETzogZG8gdGhlIHNhbWUgJ2tlZXAgb2xkIElE cycgZm9yIGdyb3VwcyBhcyB3ZWxsLgogOzs7CiA7OzsgQ29kZToKIApAQCAtMjg4LDYgKzI5 Nyw4NSBAQCAoZGVmaW5lIHJlYWQtc2hhZG93CiAoZGVmaW5lIHJlYWQtZ3JvdXAKICAgKGRh dGFiYXNlLXJlYWRlciAiL2V0Yy9ncm91cCIgc3RyaW5nLT5ncm91cC1lbnRyeSkpCiAKKyhk ZWZpbmUgKGRlY29kZS1ndWl4LWRlbGV0ZWQtdXNlcnMgZW5jb2RlZCkKKyAgKGFsaXN0LT52 aGFzaCAoY2FsbC13aXRoLWlucHV0LXN0cmluZworICAgICAgICAgICAgICAgICAgICAodXRm OC0+c3RyaW5nIChiYXNlNjQtZGVjb2RlIGVuY29kZWQpKQorICAgICAgICAgICAgICAgICAg cmVhZCkpKQorKGRlZmluZSAoZW5jb2RlLWd1aXgtZGVsZXRlZC11c2VycyBkZWxldGVkLXVz ZXJuYW1lLT5pZCkKKyAgKGRlZmluZSAobGVzcyB0aGlzIHRoYXQpCisgICAgKDwgKGNkciB0 aGlzKSAoY2RyIHRoYXQpKSkKKyAgKGJhc2U2NC1lbmNvZGUKKyAgIChzdHJpbmctPnV0ZjgK KyAgICAob2JqZWN0LT5zdHJpbmcKKyAgICAgOzsgU29ydCB0aGUgbWFwcGluZ3MsIHRvIGF2 b2lkIGhhc2hpbmcgY2F1c2luZyBub24tZGV0ZXJtaW5pc20uCisgICAgIChzb3J0CisgICAg ICAodmhhc2gtZm9sZCAobGFtYmRhICh1c2VybmFtZSB2YWx1ZSBhY2N1bXVsYXRlZCkKKyAg ICAgICAgICAgICAgICAgICAgKHVubGVzcyAoc3RyaW5nPyB1c2VybmFtZSkKKyAgICAgICAg ICAgICAgICAgICAgICAoZXJyb3IgInVzZXJuYW1lIHNob3VsZCBiZSBhIHN0cmluZyIpKQor ICAgICAgICAgICAgICAgICAgICAodW5sZXNzIChpbnRlZ2VyPyB2YWx1ZSkKKyAgICAgICAg ICAgICAgICAgICAgICAoZXJyb3IgInVpZCBzaG91bGQgYmUgYSBzdHJpbmciKSkKKyAgICAg ICAgICAgICAgICAgICAgKGNvbnMgKGNvbnMgdXNlcm5hbWUgdmFsdWUpIGFjY3VtdWxhdGVk KSkKKyAgICAgICAgICAgICAgICAgICcoKQorICAgICAgICAgICAgICAgICAgZGVsZXRlZC11 c2VybmFtZS0+aWQpCisgICAgICBsZXNzKSkpKSkKKworKGRlZmluZSAocGFzc3dkLWRlbGV0 ZWQgcGFzc3dkKQorICAoZGVmaW5lIGd1aXgtZGVsZXRlZC11c2VycworICAgICgobG9va3Vw LXByb2NlZHVyZSBwYXNzd2QgcGFzc3dvcmQtZW50cnktbmFtZSkKKyAgICAgImd1aXgtZGVs ZXRlZC11c2VycyIpKQorICAoaWYgZ3VpeC1kZWxldGVkLXVzZXJzCisgICAgICAoZGVjb2Rl LWd1aXgtZGVsZXRlZC11c2VycyAocGFzc3dvcmQtZW50cnktcmVhbC1uYW1lIGd1aXgtZGVs ZXRlZC11c2VycykpCisgICAgICB2bGlzdC1udWxsKSkKKworKGRlZmluZSAoYWRqdXN0LWRl bGV0ZWQtdXNlcnMgY3VycmVudC1wYXNzd2QtZW50cmllcyBuZXctcGFzc3dkLWVudHJpZXMK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnQtZGVsZXRlZCkKKyAgKGRl ZmluZSBsb29rdXAtYnktbmFtZS9uZXcKKyAgICAobG9va3VwLXByb2NlZHVyZSBuZXctcGFz c3dkLWVudHJpZXMgcGFzc3dvcmQtZW50cnktbmFtZSkpCisgIChkZWZpbmUgbG9va3VwLWJ5 LWlkL25ldworICAgIChsb29rdXAtcHJvY2VkdXJlIG5ldy1wYXNzd2QtZW50cmllcyBwYXNz d29yZC1lbnRyeS11aWQpKQorICAoZGVmaW5lIGxvb2t1cC1ieS1pZC9vbGQKKyAgICAobG9v a3VwLXByb2NlZHVyZSBjdXJyZW50LXBhc3N3ZC1lbnRyaWVzIHBhc3N3b3JkLWVudHJ5LXVp ZCkpCisgIDs7IFJlbW92ZSBhbGwgdXNlcm5hbWVzIG9mICdjdXJyZW50LWRlbGV0ZWQnIHRo YXQgd2VyZSBhbGxvY2F0ZWQKKyAgOzsgKGluIG5ldy1wYXNzd2QtZW50cmllcykgYW5kIHNp bWlsYXJpbHksIHJlbW92ZSBhbGwgSURzIHRoYXQgd2VyZQorICA7OyBhbGxvY2F0ZWQuCisg IChkZWZpbmUgY3VycmVudC1kZWxldGVkL2ZpbHRlcmVkCisgICAgKHZoYXNoLWZvbGQgKGxh bWJkYSAodXNlcm5hbWUgaWQgYWNjdW11bGF0ZWQpCisgICAgICAgICAgICAgICAgICAoaWYg KG9yIChsb29rdXAtYnktbmFtZS9uZXcgdXNlcm5hbWUpCisgICAgICAgICAgICAgICAgICAg ICAgICAgIChsb29rdXAtYnktaWQvbmV3IGlkKSkKKyAgICAgICAgICAgICAgICAgICAgICBh Y2N1bXVsYXRlZAorICAgICAgICAgICAgICAgICAgICAgICh2aGFzaC1jb25zIHVzZXJuYW1l IGlkIGFjY3VtdWxhdGVkKSkpCisgICAgICAgICAgICAgICAgdmxpc3QtbnVsbAorICAgICAg ICAgICAgICAgIGN1cnJlbnQtZGVsZXRlZCkpCisgIChkZWZpbmUgKGlkLXJldXNlZD8gdXNl cm5hbWUgaWQpCisgICAgOzsgV2FzIHRoZSBJRCB1c2VkIGJ5IGEgZGlmZmVyZW50IHVzZXJu YW1lIHRoYW4gVVNFUk5BTUUgaW4KKyAgICA7OyBDVVJSRU5ULVBBU1NXRC1FTlRSSUVTPwor ICAgIChsZXQgKChvbGQtcGFzc3dvcmQtZW50cnkgKGxvb2t1cC1ieS1pZC9vbGQgaWQpKSkK KyAgICAgIChhbmQgb2xkLXBhc3N3b3JkLWVudHJ5IChzdHJpbmc9PyAocGFzc3dvcmQtZW50 cnktbmFtZSBvbGQtcGFzc3dvcmQtZW50cnkpCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdXNlcm5hbWUpKSkpCisgIDs7IEFkZCB1c2VybmFtZXMgdGhhdCBh cmUgcHJlc2VudCBpbiBDVVJSRU5ULVBBU1NXRC1FTlRSSUVTIGJ1dAorICA7OyBub3QgaW4g TkVXLVBBU1NXRC1FTlRSSUVTLCBidXQgb25seSBpZiB0aGUgSUQgd2Fzbid0IHJldXNlZAor ICA7OyBmb3Igc29tZSBvdGhlciB1c2VyIG5hbWUuCisgIChkZWZpbmUgbmV3LWRlbGV0ZWQK KyAgICAoZm9sZCAobGFtYmRhICh1c2VybmFtZSBpZCBhY2N1bXVsYXRlZCkKKyAgICAgICAg ICAgIChpZiAoYW5kIChub3QgKGxvb2t1cC1ieS1uYW1lL25ldyB1c2VybmFtZSkpCisgICAg ICAgICAgICAgICAgICAgICAobm90IChpZC1yZXVzZWQ/IHVzZXJuYW1lIGlkKSkpCisgICAg ICAgICAgICAgICAgKHZoYXNoLWNvbnMgdXNlcm5hbWUgaWQgYWNjdW11bGF0ZWQpCisgICAg ICAgICAgICAgICAgYWNjdW11bGF0ZWQpKQorICAgICAgICAgIGN1cnJlbnQtZGVsZXRlZC9m aWx0ZXJlZAorICAgICAgICAgIGN1cnJlbnQtcGFzc3dkLWVudHJpZXMpKQorCisgIChkZWZp bmUgKGFkanVzdCBwYXNzd29yZC1lbnRyeSogYWNjdW11bGF0ZWQpCisgICAgKGNvbnMgKGlm IChzdHJpbmc9PyAocGFzc3dvcmQtZW50cnktbmFtZSBwYXNzd29yZC1lbnRyeSopICJndWl4 LWRlbGV0ZWQtdXNlcnMiKQorICAgICAgICAgICAgICAocGFzc3dvcmQtZW50cnkKKyAgICAg ICAgICAgICAgIChpbmhlcml0IHBhc3N3b3JkLWVudHJ5KikKKyAgICAgICAgICAgICAgIChy ZWFsLW5hbWUgKGVuY29kZS1ndWl4LWRlbGV0ZWQtdXNlcnMgbmV3LWRlbGV0ZWQpKSkKKyAg ICAgICAgICAgICAgcGFzc3dvcmQtZW50cnkqKQorICAgICAgICAgIGFjY3VtdWxhdGVkKSkK KyAgOzsgVGhlICdyZXZlcnNlJyBpcyB0byBwcmVzZXJ2ZSB0aGUgb3JkZXIgLS0gaW4gdGhl b3J5LCB0aGlzIHNob3VsZCBiZQorICA7OyB1bm5lY2Vzc2FyeSwgYnV0IHJldmVydGluZyB0 aGUgb3JkZXJpbmcgb2YgdGhlIGVudHJpZXMgaW4gL2V0Yy9wYXNzd2QKKyAgOzsgYWZ0ZXIg ZWFjaCByZWNvbmZpZ3VyYXRpb24gd291bGQgYmUgc3VycHJpc2luZy4KKyAgKGZvbGQgYWRq dXN0ICcoKSAocmV2ZXJzZSBuZXctcGFzc3dkLWVudHJpZXMpKSkKKwogDAogOzs7CiA7Ozsg QnVpbGRpbmcgZGF0YWJhc2VzLgpAQCAtMzIxLDcgKzQwOSw4IEBAIChkZWZpbmUgKHVzZXIt aWQ/IGlkKQogCiAoZGVmaW5lKiAoYWxsb2NhdGUtaWQgYXNzaWdubWVudCAjOmtleSBzeXN0 ZW0/KQogICAiUmV0dXJuIHR3byB2YWx1ZXM6IGEgbmV3bHkgYWxsb2NhdGVkIElELCBhbmQg YW4gdXBkYXRlZCA8YWxsb2NhdGlvbj4gcmVjb3JkCi1iYXNlZCBvbiBBU1NJR05NRU5ULiAg SWYgU1lTVEVNPyBpcyB0cnVlLCByZXR1cm4gYSBzeXN0ZW0gSUQuIgorYmFzZWQgb24gQVNT SUdOTUVOVC4gIElmIFNZU1RFTT8gaXMgdHJ1ZSwgcmV0dXJuIGEgc3lzdGVtIElELiAgVGhp cyByZXF1aXJlcwordGhhdCBubyBJRCBpcyBhbGxvY2F0ZWQgeWV0LiIKICAgKGRlZmluZSBu ZXh0CiAgICAgOzsgUmV0dXJuIHRoZSBuZXh0IGF2YWlsYWJsZSBJRCwgbG9vcGluZyBpZiBu ZWNlc3NhcnkuCiAgICAgKGlmIHN5c3RlbT8KQEAgLTQ0MSwyMCArNTMwLDI4IEBAIChkZWZp bmUgcHJldmlvdXMtZW50cnkKICAgICAgICAgICBnaWRzCiAgICAgICAgICAgZ3JvdXBzKSkp CiAKLShkZWZpbmUqIChhbGxvY2F0ZS1wYXNzd2QgdXNlcnMgZ3JvdXBzICM6b3B0aW9uYWwg KGN1cnJlbnQtcGFzc3dkICcoKSkpCisoZGVmaW5lKiAoYWxsb2NhdGUtcGFzc3dkIHVzZXJz IGdyb3VwcyAjOm9wdGlvbmFsIChjdXJyZW50LXBhc3N3ZCAnKCkpCisgICAgICAgICAgICAg ICAgICAgICAgICAgIChkZWxldGVkLXVzZXJuYW1lLT5pZCB2bGlzdC1udWxsKSkKICAgIlJl dHVybiBhIGxpc3Qgb2YgcGFzc3dvcmQgZW50cmllcyBmb3IgVVNFUlMsIGEgbGlzdCBvZiA8 dXNlci1hY2NvdW50Pi4KIFRha2UgR0lEcyBmcm9tIEdST1VQUywgYSBsaXN0IG9mIGdyb3Vw IGVudHJpZXMuICBSZXVzZSBVSURzIGZyb20KLUNVUlJFTlQtUEFTU1dELCBhIGxpc3Qgb2Yg cGFzc3dvcmQgZW50cmllcywgd2hlbiBwb3NzaWJsZTsgb3RoZXJ3aXNlIGFsbG9jYXRlCi1u ZXcgVUlEcy4iCitDVVJSRU5ULVBBU1NXRCwgYSBsaXN0IG9mIHBhc3N3b3JkIGVudHJpZXMs IG9yIGRlbGV0ZWQtdXNlcm5hbWUtPmlkLAorYSB2aGFzaCBvZiB1c2VybmFtZXMgdGhhdCB3 ZXJlIGRlbGV0ZWQgaW4gdGhlIHByZXZpb3VzIC9ldGMvcGFzc3dkIHRvIElEcywKK3doZW4g cG9zc2libGU7IG90aGVyd2lzZSBhbGxvY2F0ZSBuZXcgVUlEcy4iCiAgIChkZWZpbmUgdWlk cwotICAgIChyZXNlcnZlLWlkcyAocmVzZXJ2ZS1pZHMgKGFsbG9jYXRpb24pCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAobWFwIHBhc3N3b3JkLWVudHJ5LXVpZCBjdXJyZW50 LXBhc3N3ZCkpCi0gICAgICAgICAgICAgICAgIChmaWx0ZXItbWFwIHVzZXItYWNjb3VudC11 aWQgdXNlcnMpCi0gICAgICAgICAgICAgICAgICM6c2tpcD8gI2YpKQotCi0gIChkZWZpbmUg cHJldmlvdXMtZW50cnkKKyAgICAocmVzZXJ2ZS1pZHMgOyA8LS0gVE9ETzogaXMgIzpza2lw PyAjZmFsc2UgbmVlZGVkIGhlcmUgYXMgd2VsbD8KKyAgICAgKHJlc2VydmUtaWRzIChyZXNl cnZlLWlkcyAoYWxsb2NhdGlvbikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo bWFwIHBhc3N3b3JkLWVudHJ5LXVpZCBjdXJyZW50LXBhc3N3ZCkpCisgICAgICAgICAgICAg ICAgICAoZmlsdGVyLW1hcCB1c2VyLWFjY291bnQtdWlkIHVzZXJzKQorICAgICAgICAgICAg ICAgICAgIzpza2lwPyAjZikKKyAgICAgKHZoYXNoLWZvbGQgKGxhbWJkYSAodXNlcm5hbWUg aWQgYWNjdW11bGF0ZWQpCisgICAgICAgICAgICAgICAgICAgKGNvbnMgaWQgYWNjdW11bGF0 ZWQpKSAnKCkgZGVsZXRlZC11c2VybmFtZS0+aWQpKSkKKworICAoZGVmaW5lIHByZXZpb3Vz LXVuZGVsZXRlZC1lbnRyeQogICAgIChsb29rdXAtcHJvY2VkdXJlIGN1cnJlbnQtcGFzc3dk IHBhc3N3b3JkLWVudHJ5LW5hbWUpKQogCisgIChkZWZpbmUgKHByZXZpb3VzLWRlbGV0ZWQt ZW50cnkgdXNlcm5hbWUpCisgICAgKGFuZD0+ICh2aGFzaC1hc3NvYyB1c2VybmFtZSBkZWxl dGVkLXVzZXJuYW1lLT5pZCkgY2RyKSkKKwogICAoZGVmaW5lIChncm91cC1pZCBuYW1lKQog ICAgIChvciAoYW55IChsYW1iZGEgKGVudHJ5KQogICAgICAgICAgICAgICAgKGFuZCAoc3Ry aW5nPT8gKGdyb3VwLWVudHJ5LW5hbWUgZW50cnkpIG5hbWUpCkBAIC00NzEsMTcgKzU2OCwy OCBAQCAoZGVmaW5lIChncm91cC1pZCBuYW1lKQogICAgICAgICAgICAgICAgICAgKGRpcmVj dG9yeSAgICAodXNlci1hY2NvdW50LWhvbWUtZGlyZWN0b3J5IHVzZXIpKQogICAgICAgICAg ICAgICAgICAgKHNoZWxsICAgICAgICAodXNlci1hY2NvdW50LXNoZWxsIHVzZXIpKQogICAg ICAgICAgICAgICAgICAgKHN5c3RlbT8gICAgICAodXNlci1hY2NvdW50LXN5c3RlbT8gdXNl cikpKQotICAgICAgICAgICAgICAobGV0Ki12YWx1ZXMgKCgocHJldmlvdXMpCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChwcmV2aW91cy1lbnRyeSBuYW1lKSkKKyAgICAgICAg ICAgICAgKGxldCotdmFsdWVzICgoKHByZXZpb3VzLXVuZGVsZXRlZCkKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKHByZXZpb3VzLXVuZGVsZXRlZC1lbnRyeSBuYW1lKSkKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAoKHByZXZpb3VzLWRlbGV0ZWQpCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChwcmV2aW91cy1kZWxldGVkLWVudHJ5IG5hbWUpKQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICgoYWxsb2NhdGlvbiBpZCkKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKGNvbmQKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICgobnVtYmVyPyByZXF1ZXN0ZWQtaWQpCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKHZhbHVlcyAocmVzZXJ2ZS1pZHMgYWxsb2NhdGlvbgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsaXN0IHJlcXVlc3RlZC1p ZCkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXF1ZXN0ZWQt aWQpKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHByZXZpb3VzCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAocHJldmlvdXMtdW5kZWxldGVkCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKHZhbHVlcyBhbGxvY2F0aW9uCi0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAocGFzc3dvcmQtZW50cnktdWlkIHByZXZpb3Vz KSkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocGFzc3dvcmQt ZW50cnktdWlkIHByZXZpb3VzLXVuZGVsZXRlZCkpKQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKChhbmQgcHJldmlvdXMtZGVsZXRlZAorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vdCAoYWxsb2NhdGVkPyBhbGxvY2F0aW9uIHByZXZpb3VzLWRl bGV0ZWQpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7OyBUaGlzIGRlbGV0 ZWQgdXNlciBtaWdodCBzdGlsbCBoYXZlIHNvbWUgZmlsZXMKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA7OyBpbiB0aGUgZmlsZSBzeXN0ZW0sIHJldXNlIHRoZSBvbGQgaWQg c3VjaAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7IHRoYXQgaXQgcmVtYWlu cyBjb3JyZWN0LCB1bmxlc3Mgc29tZSBvdGhlcgorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDs7IHVzZXIgaGFzIGNob29zZW4gdGhhdCBpZC4KKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAodmFsdWVzIChyZXNlcnZlLWlkcyBhbGxvY2F0aW9uCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxpc3QgcHJl dmlvdXMtZGVsZXRlZCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBwcmV2aW91cy1kZWxldGVkKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChl bHNlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGFsbG9jYXRlLWlkIGFsbG9j YXRpb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIzpz eXN0ZW0/IHN5c3RlbT8pKSkpKQpAQCAtNDk0LDkgKzYwMiwxMCBAQCAoZGVmaW5lIChncm91 cC1pZCBuYW1lKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7IFVzZXJzIG1p Z2h0IGNoYW5nZSB0aGVpciBuYW1lIHRvIHNvbWV0aGluZwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDs7IG90aGVyIHRoYW4gd2hhdCB0aGUgc3lzYWRtaW4gY2hvc2UsIHdp dGgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7OyAnY2hmbicuICBUaHVzIGNv bnNpZGVyIGl0ICJzdGF0ZWZ1bCIuCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KHJlYWwtbmFtZSAoaWYgKGFuZCBwcmV2aW91cyAobm90IHN5c3RlbT8pKQotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChwYXNzd29yZC1lbnRyeS1y ZWFsLW5hbWUgcHJldmlvdXMpCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcmVhbC1uYW1lKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAocmVhbC1uYW1lCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChpZiAoYW5k IHByZXZpb3VzLXVuZGVsZXRlZCAobm90IHN5c3RlbT8pKQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKHBhc3N3b3JkLWVudHJ5LXJlYWwtbmFtZSBwcmV2aW91cy11 bmRlbGV0ZWQpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWFsLW5h bWUpKQogCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOzsgRG8gbm90IHJldXNl IHRoZSBzaGVsbCBvZiBQUkVWSU9VUyBzaW5jZSAoMSkKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA7OyB0aGF0IGNvdWxkIGxlYWQgdG8gY29uZnVzaW9uLCBhbmQgKDIpIHRo ZQpAQCAtNTU2LDYgKzY2NSwyNSBAQCAoZGVmaW5lKiAodXNlcitncm91cC1kYXRhYmFzZXMg dXNlcnMgZ3JvdXBzCiBlbnRyaWVzLCBhbmQgdGhlIGxpc3Qgb2Ygc2hhZG93IGVudHJpZXMg Y29ycmVzcG9uZGluZyB0byBVU0VSUyBhbmQgR1JPVVBTLgogUHJlc2VydmUgc3RhdGVmdWwg Yml0cyBmcm9tIENVUlJFTlQtUEFTU1dELCBDVVJSRU5ULUdST1VQUywgYW5kCiBDVVJSRU5U LVNIQURPVzogVUlEcywgR0lEcywgcGFzc3dvcmRzLCB1c2VyIHNoZWxscywgZXRjLiIKKyAg KGRlZmluZSB1c2VycyoKKyAgICAoaWYgKChsb29rdXAtcHJvY2VkdXJlIHVzZXJzIHVzZXIt YWNjb3VudC1uYW1lKQorICAgICAgICAgImd1aXgtZGVsZXRlZC11c2VycyIpCisgICAgICAg IHVzZXJzCisgICAgICAgIChhcHBlbmQgdXNlcnMKKyAgICAgICAgICAgICAgICAobGlzdCAo dXNlci1hY2NvdW50CisgICAgICAgICAgICAgICAgICAgICAgIChuYW1lICJndWl4LWRlbGV0 ZWQtdXNlcnMiKQorICAgICAgICAgICAgICAgICAgICAgICAoZ3JvdXAgImd1aXgtZGVsZXRl ZC11c2VycyIpCisgICAgICAgICAgICAgICAgICAgICAgIChob21lLWRpcmVjdG9yeSAiL3Zh ci9lbXB0eSIpCisgICAgICAgICAgICAgICAgICAgICAgIChzeXN0ZW0/ICN0cnVlKSkpKSkp CisgIChkZWZpbmUgZ3JvdXBzKgorICAgIChpZiAoKGxvb2t1cC1wcm9jZWR1cmUgZ3JvdXBz IHVzZXItZ3JvdXAtbmFtZSkKKyAgICAgICAgICJndWl4LWRlbGV0ZWQtdXNlcnMiKQorICAg ICAgICBncm91cHMKKyAgICAgICAgKGFwcGVuZCBncm91cHMKKyAgICAgICAgICAgICAgICAo bGlzdCAodXNlci1ncm91cAorICAgICAgICAgICAgICAgICAgICAgICAobmFtZSAiZ3VpeC1k ZWxldGVkLXVzZXJzIikKKyAgICAgICAgICAgICAgICAgICAgICAgKHN5c3RlbT8gI3RydWUp KSkpKSkKKwogICAoZGVmaW5lIG1lbWJlcnMKICAgICA7OyBNYXAgZ3JvdXAgbmFtZSB0byB1 c2VyIG5hbWVzLgogICAgIChmb2xkIChsYW1iZGEgKHVzZXIgbWVtYmVycykKQEAgLTU2Mywx NiArNjkxLDI0IEBAIChkZWZpbmUgbWVtYmVycwogICAgICAgICAgICAgICAgICAgbWVtYmVy cwogICAgICAgICAgICAgICAgICAgKHVzZXItYWNjb3VudC1zdXBwbGVtZW50YXJ5LWdyb3Vw cyB1c2VyKSkpCiAgICAgICAgICAgdmxpc3QtbnVsbAotICAgICAgICAgIHVzZXJzKSkKKyAg ICAgICAgICB1c2VycyopKQorCisgIChkZWZpbmUgY3VycmVudC1kZWxldGVkIChwYXNzd2Qt ZGVsZXRlZCBjdXJyZW50LXBhc3N3ZCkpCiAKICAgKGRlZmluZSBncm91cC1lbnRyaWVzCi0g ICAgKGFsbG9jYXRlLWdyb3VwcyBncm91cHMgbWVtYmVycyBjdXJyZW50LWdyb3VwcykpCisg ICAgKGFsbG9jYXRlLWdyb3VwcyBncm91cHMqIG1lbWJlcnMgY3VycmVudC1ncm91cHMpKQog CiAgIChkZWZpbmUgcGFzc3dkLWVudHJpZXMKLSAgICAoYWxsb2NhdGUtcGFzc3dkIHVzZXJz IGdyb3VwLWVudHJpZXMgY3VycmVudC1wYXNzd2QpKQorICAgIChhbGxvY2F0ZS1wYXNzd2Qg dXNlcnMqIGdyb3VwLWVudHJpZXMgY3VycmVudC1wYXNzd2QKKyAgICAgICAgICAgICAgICAg ICAgIChwYXNzd2QtZGVsZXRlZCBjdXJyZW50LXBhc3N3ZCkpKQogCiAgIChkZWZpbmUgc2hh ZG93LWVudHJpZXMKLSAgICAocGFzc3dkLT5zaGFkb3cgdXNlcnMgcGFzc3dkLWVudHJpZXMg Y3VycmVudC1zaGFkb3cKKyAgICAocGFzc3dkLT5zaGFkb3cgdXNlcnMqIHBhc3N3ZC1lbnRy aWVzIGN1cnJlbnQtc2hhZG93CiAgICAgICAgICAgICAgICAgICAgICM6Y3VycmVudC10aW1l IGN1cnJlbnQtdGltZSkpCiAKLSAgKHZhbHVlcyBncm91cC1lbnRyaWVzIHBhc3N3ZC1lbnRy aWVzIHNoYWRvdy1lbnRyaWVzKSkKKyAgOzsgVE9ETzogYWRqdXN0IG5ldyAnZGVsZXRlZCcK KyAgKHZhbHVlcyBncm91cC1lbnRyaWVzIChhZGp1c3QtZGVsZXRlZC11c2VycworICAgICAg ICAgICAgICAgICAgICAgICAgIGN1cnJlbnQtcGFzc3dkCisgICAgICAgICAgICAgICAgICAg ICAgICAgcGFzc3dkLWVudHJpZXMKKyAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50 LWRlbGV0ZWQpCisgICAgICAgICAgc2hhZG93LWVudHJpZXMpKQpkaWZmIC0tZ2l0IGEvdGVz dHMvYWNjb3VudHMuc2NtIGIvdGVzdHMvYWNjb3VudHMuc2NtCmluZGV4IDc4MTM2MzkwYmIu LjRlMjliZmUyODUgMTAwNjQ0Ci0tLSBhL3Rlc3RzL2FjY291bnRzLnNjbQorKysgYi90ZXN0 cy9hY2NvdW50cy5zY20KQEAgLTEsNSArMSw2IEBACiA7OzsgR05VIEd1aXggLS0tIEZ1bmN0 aW9uYWwgcGFja2FnZSBtYW5hZ2VtZW50IGZvciBHTlUKIDs7OyBDb3B5cmlnaHQgwqkgMjAx OSBMdWRvdmljIENvdXJ0w6hzIDxsdWRvQGdudS5vcmc+Cis7OzsgQ29weXJpZ2h0IMKpIDIw MjIgTWF4aW1lIERldm9zIDxtYXhpbWVkZXZvc0B0ZWxlbmV0LmJlPgogOzs7CiA7OzsgVGhp cyBmaWxlIGlzIHBhcnQgb2YgR05VIEd1aXguCiA7OzsKQEAgLTI3Miw3ICsyNzMsOSBAQCAo ZGVmaW5lIGFsbG9jYXRlLXBhc3N3ZCAoQEAgKGdudSBidWlsZCBhY2NvdW50cykgYWxsb2Nh dGUtcGFzc3dkKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgIChtZW1iZXJzICcoImJv YiIpKSkKICAgICAgICAgICAgICAgKGdyb3VwLWVudHJ5IChuYW1lICJiIikgKGdpZCAoKyAx ICVpZC1taW4pKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgKG1lbWJlcnMgJygiYWxp Y2UiKSkpCi0gICAgICAgICAgICAgIChncm91cC1lbnRyeSAobmFtZSAicyIpIChnaWQgJXN5 c3RlbS1pZC1tYXgpKSkKKyAgICAgICAgICAgICAgKGdyb3VwLWVudHJ5IChuYW1lICJzIikg KGdpZCAlc3lzdGVtLWlkLW1heCkpCisgICAgICAgICAgICAgIChncm91cC1lbnRyeSAobmFt ZSAiZ3VpeC1kZWxldGVkLXVzZXJzIikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIChn aWQgKC0gJXN5c3RlbS1pZC1tYXggMSkpKSkKICAgICAgICAgKGxpc3QgKHBhc3N3b3JkLWVu dHJ5IChuYW1lICJhbGljZSIpIChyZWFsLW5hbWUgIkFsaWNlIikKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICh1aWQgJWlkLW1pbikgKGdpZCAlaWQtbWluKQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKGRpcmVjdG9yeSAiL2EiKSkKQEAgLTI4MSwxMiArMjg0 LDE5IEBAIChkZWZpbmUgYWxsb2NhdGUtcGFzc3dkIChAQCAoZ251IGJ1aWxkIGFjY291bnRz KSBhbGxvY2F0ZS1wYXNzd2QpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGRp cmVjdG9yeSAiL2IiKSkKICAgICAgICAgICAgICAgKHBhc3N3b3JkLWVudHJ5IChuYW1lICJu b2JvZHkiKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHVpZCA2NTUzNCkgKGdp ZCAlc3lzdGVtLWlkLW1heCkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChkaXJl Y3RvcnkgIi92YXIvZW1wdHkiKSkKKyAgICAgICAgICAgICAgKHBhc3N3b3JkLWVudHJ5IChu YW1lICJndWl4LWRlbGV0ZWQtdXNlcnMiKQorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgOzsgZW1wdHkgbGlzdCwgc3RhcnQgd2l0aG91dCBkZWxldGVkIHVzZXJzCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAocmVhbC1uYW1lICJLQ2s9IikKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICh1aWQgJXN5c3RlbS1pZC1tYXgpCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAoZ2lkICgtICVzeXN0ZW0taWQtbWF4IDEpKSA7IFhYWDogd2h5 IG5vdCAlc3lzdGVtLWlkLW1heD8gIEJ1ZyBvciBPSz8KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChkaXJlY3RvcnkgIi92YXIvZW1wdHkiKSkpCiAgICAgICAgIChsaXN0IChz aGFkb3ctZW50cnkgKG5hbWUgImFsaWNlIikgKGxhc3QtY2hhbmdlIDEwMCkKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAocGFzc3dvcmQgKGNyeXB0ICJpbml0aWFsIHBhc3MiICIk NiQiKSkpCiAgICAgICAgICAgICAgIChzaGFkb3ctZW50cnkgKG5hbWUgImJvYiIpIChsYXN0 LWNoYW5nZSA1MCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocGFzc3dvcmQgKGNy eXB0ICJmb28iICIkNiQiKSkpCi0gICAgICAgICAgICAgIChzaGFkb3ctZW50cnkgKG5hbWUg Im5vYm9keSIpIChsYXN0LWNoYW5nZSAxMDApKSkpCisgICAgICAgICAgICAgIChzaGFkb3ct ZW50cnkgKG5hbWUgIm5vYm9keSIpIChsYXN0LWNoYW5nZSAxMDApKQorICAgICAgICAgICAg ICAoc2hhZG93LWVudHJ5IChuYW1lICJndWl4LWRlbGV0ZWQtdXNlcnMiKSAobGFzdC1jaGFu Z2UgMTAwKSkpKQogICAoY2FsbC13aXRoLXZhbHVlcwogICAgICAgKGxhbWJkYSAoKQogICAg ICAgICAodXNlcitncm91cC1kYXRhYmFzZXMgKGxpc3QgKHVzZXItYWNjb3VudAoKYmFzZS1j b21taXQ6IDE3ZjY0NmFlYmEzOWYwZDI5N2Y2YzkxMWQ4M2IzYmQ5ZTg4YTIyN2IKcHJlcmVx dWlzaXRlLXBhdGNoLWlkOiAxZjdjNDVjZjI0ODBmNGU2ZjFlOTU2MzY2MGUxYjczYTg2ODI0 MjVlCnByZXJlcXVpc2l0ZS1wYXRjaC1pZDogMGNhYWMzMTE4NzVlZTM5Y2I0ODU3MzY1N2Vi Yjk2MGU5MGRhNmRmYgpwcmVyZXF1aXNpdGUtcGF0Y2gtaWQ6IDQxODI4NTQ5M2Q4OWViZjEw MjE3NTkwMmQ5YjA5YTAxNzRlODgxOTAKcHJlcmVxdWlzaXRlLXBhdGNoLWlkOiAzYzM5ZWI4 MzlkOWQzZmYzZmNhNmNkOTg2MjFhNWQ1YzQxMWI3YWY0CnByZXJlcXVpc2l0ZS1wYXRjaC1p ZDogOGQ1NjYyZTg3NGM0NjlmNWVlNDk2ZWY1MTgxY2YyZDBhMzBhZDFkOApwcmVyZXF1aXNp dGUtcGF0Y2gtaWQ6IDI2NTEzYzNiM2I4Njk2M2RmNzE4ZWU0MWQxNGEyNWQxY2M2YThmM2YK cHJlcmVxdWlzaXRlLXBhdGNoLWlkOiAyYjI0OTdlMmVkZWMwYWZjNDhlYmFkZDZmMDlmMGM2 NjFjNDY2MTI3CnByZXJlcXVpc2l0ZS1wYXRjaC1pZDogMjcxMmVmYjk3YmYzMzk4NWZkMDY1 OGU0ZGQ4ZTkzNmRjMDhiZTVmZQpwcmVyZXF1aXNpdGUtcGF0Y2gtaWQ6IDlkMjQwOWI0ODBh OGJmZjBmZWYwMjliNGIwOTU5MjJkNDk1N2UwNmYKcHJlcmVxdWlzaXRlLXBhdGNoLWlkOiA1 MWEzMmFiY2EzZWZlYzFiYTY3ZWFkNTliODY5NGM1ZWEzMTI5YWQzCnByZXJlcXVpc2l0ZS1w YXRjaC1pZDogN2Q1NWUzYjM5ZWI4ODAzZjA1ODg1N2Q0NDEyNzk2YjNmNWRjMDg1NgpwcmVy ZXF1aXNpdGUtcGF0Y2gtaWQ6IDkwOTI5Mjc3NjFhMzQwYzA3YTk5ZjVmM2VkMzE0YTZhZGQw NGNkZWUKcHJlcmVxdWlzaXRlLXBhdGNoLWlkOiBlYWZlZWJhMWU2ODE2ZGVlM2Y4ZGY2NzE2 MzFiYmViNWMzNzMyMzdhCi0tIAoyLjM3LjMKCg== --------------n0aORaGnf7ZoTpwNBOcR47qk Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------n0aORaGnf7ZoTpwNBOcR47qk-- --------------5TFhG3tH0dVn3brDeQ29Kal4-- --------------HpdMtMHClxb1SVem0RL9QZMu Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYycNjAUDAAAAAAAKCRBJ4+4iGRcl7pG2 AQDyzDQGkTe768lujCasN+FEVunBxwI0mJ6BYg1nWJHoVQEA0KHt7qFKiu12LtTjQZ/VakHgELQH mGWr//5k2cSpHAo= =Nxuc -----END PGP SIGNATURE----- --------------HpdMtMHClxb1SVem0RL9QZMu--