Debian Bug report logs - #497514
coreutils: chmod, chown, and chgrp change ctime even when no change was necessary

Full log

Message #85 received at [email protected] (full text, mbox, reply):

Received: (at 497514) by bugs.debian.org; 15 Sep 2008 09:23:23 +0000
From [email protected] Mon Sep 15 09:23:22 2008
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rietz.debian.org
X-Spam-Level: 
X-Spam-Bayes: score:0.0000 Tokens: new, 81; hammy, 150; neutral, 112; spammy,
	1. spammytokens:0.987-1--tte hammytokens:0.000-+--H*u:1.5.13,
	0.000-+--H*u:2006-08-11, 0.000-+--i686, 0.000-+--H*UA:1.5.13,
	0.000-+--H*UA:2006-08-11
X-Spam-Status: No, score=-10.9 required=4.0 tests=BAYES_00,FOURLA,
	HAS_BUG_NUMBER,RCVD_IN_DNSWL_MED autolearn=ham
	version=3.2.3-bugs.debian.org_2005_01_02
Return-path: <[email protected]>
Received: from relay2-v.mail.gandi.net ([217.70.178.76])
	by rietz.debian.org with esmtp (Exim 4.63)
	(envelope-from <[email protected]>)
	id 1KfAIk-0006tB-Bg
	for [email protected]; Mon, 15 Sep 2008 09:23:22 +0000
Received: from localhost (mfilter2-v.gandi.net [217.70.178.36])
	by relay2-v.mail.gandi.net (Postfix) with ESMTP id 99FBB135DA;
	Mon, 15 Sep 2008 11:23:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter2-v.mgt.gandi.net
Received: from relay2-v.mail.gandi.net ([217.70.178.76])
	by localhost (mfilter2-v.gandi.net [217.70.178.36]) (amavisd-new, port 10024)
	with ESMTP id mX65mTNFiYQE; Mon, 15 Sep 2008 11:23:02 +0200 (CEST)
Received: from smtp.lan.rossen.ch (cix-adsl-c38-p084.vtx.ch [212.147.38.84])
	by relay2-v.mail.gandi.net (Postfix) with ESMTP id 9F16B135D8;
	Mon, 15 Sep 2008 11:22:47 +0200 (CEST)
Received: from localhost (durian.lan.rossen.ch [192.168.71.253])
	by smtp.lan.rossen.ch (Postfix) with ESMTP id 32895140420C;
	Mon, 15 Sep 2008 11:22:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at rossen.ch
Received: from smtp.lan.rossen.ch ([192.168.71.253])
	by localhost (durian.lan.rossen.ch [192.168.71.253]) (amavisd-new, port 10024)
	with ESMTP id w4rUO8tWxvDw; Mon, 15 Sep 2008 11:22:47 +0200 (CEST)
Received: from smtp.lan.rossen.ch (durian.lan.rossen.ch [192.168.71.253])
	by SA-filtered (Postfix) with ESMTP id 1024B140420D;
	Mon, 15 Sep 2008 11:22:43 +0200 (CEST)
Received: from mango (durian.lan.rossen.ch [192.168.71.253])
	by smtp.lan.rossen.ch (Postfix) with SMTP id EDBE4140420C;
	Mon, 15 Sep 2008 11:22:41 +0200 (CEST)
Received: by mango (sSMTP sendmail emulation); Mon, 15 Sep 2008 11:22:41 +0200
Date: Mon, 15 Sep 2008 11:22:41 +0200
From: Erik Rossen <[email protected]>
To: Michael Stone <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <[email protected]>
User-Agent: Mutt/1.5.13 (2006-08-11)
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 02, 2008 at 10:48:30AM -0400, Michael Stone wrote:
> On Tue, Sep 02, 2008 at 03:50:16PM +0200, Erik Rossen wrote:
> >But it would be so much more elegant if chmod just Did The Right Thing.
> 
> It's certainly arguable whether adding another non-standard flag is the 
> Right Thing when it's fairly trivial to get the result in a more 
> portable fashion using find(1).

It seems that the FreeBSD people think that making a change to the
filesystem only when necessary is The Right Thing.  But I guess that
argument carries no weight in GNU. ;-)

> >Can I ask you to pass along this wishlist item to upstream and maybe ask
> >them why ctime must be modified even when the permissions are not?  I
> >would really like to know why.
> 
> Upstream monitors the debian bug logs and will presumably chime in if 
> interested. I vaguely recall that people want these utilities to act 
> even if not strictly necessary because of possible side effects for 
> extended attributes.
> 
> Mike Stone

I took your advice (paraphrased: "try another tool") and I now have
three options for fixing file permissions without disturbing the file
system too much:

1.  find + chmod : classic but ugly

2.  cfengine : Does The Right Thing, but difficult to do as a one-liner
unless you are already using cfengine for other stuff

3.  setfacl -R : nice.  Does The Right Thing as a fairly simple one-liner

setfacl is kind of interesting.  Even if the filesystem is mounted
without extended ACLs enabled, it works for setting the POSIX ACLs and
it Does The Right Thing.  For example, I can do

	setfacl -R -m u::rwX,g::rwX,o:rX shares/

to fix every file and directory in "shares" to be readable, and writable
only by the owner and group of shares.  And if I run the same command
again, stat shows that the ctime has not changed unless it was necessary
to modify the permissions of a file or directory.

I am pretty happy about this solution and I intend to use it in cases
where there is a integrity-checker in place and no cfengine.

But while doing my tests, I noticed something strange about setfacl: if
the filesystem is mounted with extended ACLs enabled (on a ext3 fs), it
is possible to use setfacl to make changes to file permissions and CTIME
IS NEVER MODIFIED EVEN IF PERMISSIONS ARE MODIFIED.  I thought that this
was supposed to be impossible, but perhaps this is a known side-effect
("feature") of activating extended ACLs on ext3.

Can anyone else confirm this?  I am running etch with an ext3 filesystem
that was created in June 2008. This is my "uname -a":

	Linux mango 2.6.18-6-vserver-686 #1 SMP Mon Aug 18 11:11:15 UTC 2008 i686 GNU/Linux


-- 
Erik Rossen                               OpenPGP key: 2935D0B9
[email protected]                          On fonce la tête dans
http://www.rtfm-sarl.ch                   le guidon et on RTFM.

Send a report that this bug log contains spam.