From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-79423-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 08B7C139085 for <garchives@archives.gentoo.org>; Mon, 30 Jan 2017 18:06:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 298B4224246; Mon, 30 Jan 2017 18:06:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D9E7B22423D for <gentoo-dev@lists.gentoo.org>; Mon, 30 Jan 2017 18:06:01 +0000 (UTC) Received: from patrickm (unknown [100.42.98.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: chutzpah) by smtp.gentoo.org (Postfix) with ESMTPSA id 74A4033BF1C; Mon, 30 Jan 2017 18:06:00 +0000 (UTC) Date: Mon, 30 Jan 2017 10:05:57 -0800 From: Patrick McLean <chutzpah@gentoo.org> To: Michael Orlitzky <mjo@gentoo.org> Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Requirements for UID/GID management Message-ID: <20170130100557.49b3b77e@patrickm> In-Reply-To: <513d3ceb-9e07-096a-ff5c-2cf8a5c2a6fd@gentoo.org> References: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org> <CAGfcS_=biacBM0xsy0GX3_X0mOAd3BdgHDXYorSBkmwsoQ9sgQ@mail.gmail.com> <ee24eb83-4430-40ff-07d0-577bc188457d@gentoo.org> <CAGfcS_=V+xmBU+fFbMQBH39E9-y9CUaZt9Bok80Wg6_jboHcbQ@mail.gmail.com> <20170127183752.500f8910@patrickm> <CAGfcS_kcXOa+NC5Eh_qGb95uEaaKsarjsK92jOuTpUB=P5sXxg@mail.gmail.com> <4a8204d4-929e-6260-957a-dcf8f82f4b24@gentoo.org> <c350f01e-0bf8-f7b4-cfa0-ce6a9575e5e2@gmail.com> <9bceefb9-f7d2-06a4-2304-d31f627f7656@gentoo.org> <3fd11559-004c-11f8-609a-923ebc074539@gmail.com> <495556ab-637c-6b21-fac0-52d3bd1e4986@gentoo.org> <616a4068-8581-bce6-3359-50b1ff5a817d@gmail.com> <8eb6fc27-8504-ad7d-7ad1-7272da662178@gentoo.org> <8bfa7182-7a02-7ecb-42d1-37c2d130f586@gmail.com> <513d3ceb-9e07-096a-ff5c-2cf8a5c2a6fd@gentoo.org> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 85d59b50-2ba1-4574-872c-b7a125d82db5 X-Archives-Hash: 8cfd10f8c09daa1d6295583febc2d33d On Mon, 30 Jan 2017 11:29:02 -0500 Michael Orlitzky <mjo@gentoo.org> wrote: > On 01/30/2017 09:25 AM, Alan McKinnon wrote: > >> > >> Any user can create a hard link in its home directory > >> to /etc/shadow, so long as (a) they live on the same filesystem, > >> and (b) there are no special kernel protections in place to > >> prevent it. If you call chown on that hard link, it will change > >> the ownership of /etc/shadow. > > > > That is absolutely not true, at least for the case of classic Unix > > filesystems. > > > > ... > > > > I cannot chmod, chown or chgrp > > /etc/shadow because I do not own it, and the kernel will not let me > > ln it either: > > > > alan@khamul /alan $ ln /etc/shadow > > ln: failed to create hard link './shadow' => '/etc/shadow': > > Operation not permitted > > > > You have the fs.protected_hardlinks sysctl enabled. We patch that in > gentoo-sources, but it's off by default in vanilla-sources. Try again > with it disabled (and don't forget to turn it back on). Once the hard > link has been created, a "chown -R foo /alan" or the equivalent "find > ..." command will change the ownership of /etc/shadow. > > No, that is also enabled by default on vanilla kernels, I just verified on my machine running a vanilla kernel. It doesn't matter anyway, since the permissions and ownership information is stored in the inode, not the dentry so all hardlinks have exactly the same permissions.