From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 475B95A026D for ; Thu, 7 Sep 2023 02:21:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694046096; 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=k6dK03AfrU8iCuir0oDtfpmXlGo+dMIp0hEBoQx6TVc=; b=CrsuHMmAyB6OuJLXcDpdBky4u3/ZnV49MKZ0EiZpGaqjb+Ms435jAnp5MidFBRR/vcUf8H wjGWmzNAPL6vM9V6Mj+mDQJ0A+r2INZyzP6dgP1yDLaIWyaGYRslSgPTl/lQBYiOPpT+XV XbW7tflaJxKW70sH+5EgqbfyaXtuVLE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-626-bPgpdhrRNF6l43U1eBkbSA-1; Wed, 06 Sep 2023 20:21:31 -0400 X-MC-Unique: bPgpdhrRNF6l43U1eBkbSA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E09B689CB00; Thu, 7 Sep 2023 00:21:30 +0000 (UTC) Received: from elisabeth (unknown [10.39.208.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0EF32140E968; Thu, 7 Sep 2023 00:21:29 +0000 (UTC) Date: Thu, 7 Sep 2023 02:21:22 +0200 From: Stefano Brivio To: "Richard W.M. Jones" Subject: Re: [PATCH] fedora: Replace pasta hard links by copies, mangle Build-IDs Message-ID: <20230907022122.4ccf31ae@elisabeth> In-Reply-To: <20230823143146.GQ7636@redhat.com> References: <20230823134844.2188790-1-sbrivio@redhat.com> <20230823135327.GP7636@redhat.com> <20230823155939.7f603ffa@elisabeth> <20230823143146.GQ7636@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: MRRWN2NQBLA4RSCCN7NWOLS6L4XE6KMR X-Message-ID-Hash: MRRWN2NQBLA4RSCCN7NWOLS6L4XE6KMR X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@lists.fedoraproject.org, passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 23 Aug 2023 15:31:46 +0100 "Richard W.M. Jones" wrote: > On Wed, Aug 23, 2023 at 03:59:39PM +0200, Stefano Brivio wrote: > > On Wed, 23 Aug 2023 14:53:27 +0100 > > "Richard W.M. Jones" wrote: > > > > > On Wed, Aug 23, 2023 at 03:48:44PM +0200, Stefano Brivio wrote: > > > > The hard link trick didn't actually fix the issue with SELinux file > > > > contexts properly: as opposed to symbolic links, SELinux now > > > > correctly associates types to the labels that are set -- except that > > > > those labels are now shared, so we can end up (depending on how > > > > rpm(8) extracts the archives) with /usr/bin/passt having a > > > > pasta_exec_t context. > > > > > > > > This got rather confusing as running restorecon(8) seemed to fix up > > > > labels -- but that's simply toggling between passt_exec_t and > > > > pasta_exec_t for both links, because each invocation will just "fix" > > > > the file with the mismatching context. > > > > > > > > Replace the hard links with copies. AppArmor's attachment, instead, > > > > works with hard links, and if there's no LSM, we can keep symbolic > > > > links, so keep symbolic links in the Makefile. > > > > > > > > With copies, rpmbuild(8) will warn about duplicate Build-IDs in the > > > > same package. Mangle them in pasta binaries by summing one to the > > > > last byte, modulo one byte, using xxd (provided by vim-common) and > > > > disable the automatic rehashing by find-debuginfo(1) -- we already > > > > have per-release Build-IDs thanks to $VERSION passed on 'make'. > > > > > > Right, this ^ was going to be my comment. RPM doesn't like having two > > > identical copies of a file. > > > > In which other way, though? cpio(1) is fine with it, and I tried to > > install the package on both ext4 and xfs -- the only warning I got was > > the (semi-reasonable) one from rpmbuild about duplicate Build-IDs. > > I'm fairly sure I've seen an error when you have two identical files; ...but those are not identical, exactly because I change the Build-ID. > it might only happen in Koji. Anyway, hacking the binary is surely > wrong, but let's hear the opinions of the Fedora / SELinux developers. I don't see why it would be "surely wrong". It's surely ugly, though, and David suggested that two separate builds might be slightly less ugly, albeit (more) wasteful, but passt takes seconds to build, after all. New patch posted. -- Stefano