Message-ID: <20230706210236.GB3244704@millbarge>
Date: Thu, 6 Jul 2023 21:02:36 +0000
From: Seth Arnold <seth.arnold@...onical.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: Damien Le Moal <dlemoal@...nel.org>, jk@...abs.org, arnd@...db.de,
	mpe@...erman.id.au, npiggin@...il.com, christophe.leroy@...roup.eu,
	hca@...ux.ibm.com, gor@...ux.ibm.com, agordeev@...ux.ibm.com,
	borntraeger@...ux.ibm.com, svens@...ux.ibm.com,
	gregkh@...uxfoundation.org, arve@...roid.com, tkjos@...roid.com,
	maco@...roid.com, joel@...lfernandes.org, brauner@...nel.org,
	cmllamas@...gle.com, surenb@...gle.com,
	dennis.dalessandro@...nelisnetworks.com, jgg@...pe.ca,
	leon@...nel.org, bwarrum@...ux.ibm.com, rituagar@...ux.ibm.com,
	ericvh@...nel.org, lucho@...kov.net, asmadeus@...ewreck.org,
	linux_oss@...debyte.com, dsterba@...e.com, dhowells@...hat.com,
	marc.dionne@...istor.com, viro@...iv.linux.org.uk, raven@...maw.net,
	luisbg@...nel.org, salah.triki@...il.com, aivazian.tigran@...il.com,
	ebiederm@...ssion.com, keescook@...omium.org, clm@...com,
	josef@...icpanda.com, xiubli@...hat.com, idryomov@...il.com,
	jaharkes@...cmu.edu, coda@...cmu.edu, jlbec@...lplan.org,
	hch@....de, nico@...xnic.net, rafael@...nel.org, code@...icks.com,
	ardb@...nel.org, xiang@...nel.org, chao@...nel.org,
	huyue2@...lpad.com, jefflexu@...ux.alibaba.com,
	linkinjeon@...nel.org, sj1557.seo@...sung.com, jack@...e.com,
	tytso@....edu, adilger.kernel@...ger.ca, jaegeuk@...nel.org,
	hirofumi@...l.parknet.co.jp, miklos@...redi.hu, rpeterso@...hat.com,
	agruenba@...hat.com, richard@....at,
	anton.ivanov@...bridgegreys.com, johannes@...solutions.net,
	mikulas@...ax.karlin.mff.cuni.cz, mike.kravetz@...cle.com,
	muchun.song@...ux.dev, dwmw2@...radead.org, shaggy@...nel.org,
	tj@...nel.org, trond.myklebust@...merspace.com, anna@...nel.org,
	chuck.lever@...cle.com, neilb@...e.de, kolga@...app.com,
	Dai.Ngo@...cle.com, tom@...pey.com, konishi.ryusuke@...il.com,
	anton@...era.com, almaz.alexandrovich@...agon-software.com,
	mark@...heh.com, joseph.qi@...ux.alibaba.com, me@...copeland.com,
	hubcap@...ibond.com, martin@...ibond.com, amir73il@...il.com,
	mcgrof@...nel.org, yzaikin@...gle.com, tony.luck@...el.com,
	gpiccoli@...lia.com, al@...rsen.net, sfrench@...ba.org,
	pc@...guebit.com, lsahlber@...hat.com, sprasad@...rosoft.com,
	senozhatsky@...omium.org, phillip@...ashfs.org.uk,
	rostedt@...dmis.org, mhiramat@...nel.org, dushistov@...l.ru,
	hdegoede@...hat.com, djwong@...nel.org, naohiro.aota@....com,
	jth@...nel.org, ast@...nel.org, daniel@...earbox.net,
	andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org,
	yhs@...com, john.fastabend@...il.com, kpsingh@...nel.org,
	sdf@...gle.com, haoluo@...gle.com, jolsa@...nel.org,
	hughd@...gle.com, akpm@...ux-foundation.org, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	john.johansen@...onical.com, paul@...l-moore.com, jmorris@...ei.org,
	serge@...lyn.com, stephen.smalley.work@...il.com,
	eparis@...isplace.org, jgross@...e.com, stern@...land.harvard.edu,
	lrh2000@....edu.cn, sebastian.reichel@...labora.com,
	wsa+renesas@...g-engineering.com, quic_ugoswami@...cinc.com,
	quic_linyyuan@...cinc.com, john@...ping.me.uk, error27@...il.com,
	quic_uaggarwa@...cinc.com, hayama@...eo.co.jp, jomajm@...il.com,
	axboe@...nel.dk, dhavale@...gle.com, dchinner@...hat.com,
	hannes@...xchg.org, zhangpeng362@...wei.com, slava@...eyko.com,
	gargaditya08@...e.com, penguin-kernel@...ove.SAKURA.ne.jp,
	yifeliu@...stonybrook.edu, madkar@...stonybrook.edu,
	ezk@...stonybrook.edu, yuzhe@...china.com, willy@...radead.org,
	okanatov@...il.com, jeffxu@...omium.org, linux@...blig.org,
	mirimmad17@...il.com, yijiangshan@...inos.cn,
	yang.yang29@....com.cn, xu.xin16@....com.cn,
	chengzhihao1@...wei.com, shr@...kernel.io, Liam.Howlett@...cle.com,
	adobriyan@...il.com, chi.minghao@....com.cn,
	roberto.sassu@...wei.com, linuszeng@...cent.com, bvanassche@....org,
	zohar@...ux.ibm.com, yi.zhang@...wei.com, trix@...hat.com,
	fmdefrancesco@...il.com, ebiggers@...gle.com,
	princekumarmaurya06@...il.com, chenzhongjin@...wei.com,
	riel@...riel.com, shaozhengchao@...wei.com, jingyuwang_vip@....com,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org,
	linux-usb@...r.kernel.org, v9fs@...ts.linux.dev,
	linux-fsdevel@...r.kernel.org, linux-afs@...ts.infradead.org,
	autofs@...r.kernel.org, linux-mm@...ck.org,
	linux-btrfs@...r.kernel.org, ceph-devel@...r.kernel.org,
	codalist@...a.cs.cmu.edu, ecryptfs@...r.kernel.org,
	linux-efi@...r.kernel.org, linux-erofs@...ts.ozlabs.org,
	linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
	cluster-devel@...hat.com, linux-um@...ts.infradead.org,
	linux-mtd@...ts.infradead.org, jfs-discussion@...ts.sourceforge.net,
	linux-nfs@...r.kernel.org, linux-nilfs@...r.kernel.org,
	linux-ntfs-dev@...ts.sourceforge.net, ntfs3@...ts.linux.dev,
	ocfs2-devel@...ts.linux.dev,
	linux-karma-devel@...ts.sourceforge.net, devel@...ts.orangefs.org,
	linux-unionfs@...r.kernel.org, linux-hardening@...r.kernel.org,
	reiserfs-devel@...r.kernel.org, linux-cifs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-trace-kernel@...r.kernel.org,
	linux-xfs@...r.kernel.org, bpf@...r.kernel.org,
	netdev@...r.kernel.org, apparmor@...ts.ubuntu.com,
	linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [apparmor] [PATCH v2 08/92] fs: new helper:
 simple_rename_timestamp

On Wed, Jul 05, 2023 at 08:04:41PM -0400, Jeff Layton wrote:
> 
> I don't believe it's an issue. I've seen nothing in the POSIX spec that
> mandates that timestamp updates to different inodes involved in an
> operation be set to the _same_ value. It just says they must be updated.
> 
> It's also hard to believe that any software would depend on this either,
> given that it's very inconsistent across filesystems today. AFAICT, this
> was mostly done in the past just as a matter of convenience.

I've seen this assumption in several programs:

mutt buffy.c
https://sources.debian.org/src/mutt/2.2.9-1/buffy.c/?hl=625#L625

  if (mailbox->newly_created &&
      (sb->st_ctime != sb->st_mtime || sb->st_ctime != sb->st_atime))
    mailbox->newly_created = 0;


neomutt mbox/mbox.c
https://sources.debian.org/src/neomutt/20220429+dfsg1-4.1/mbox/mbox.c/?hl=1820#L1820

  if (m->newly_created && ((st.st_ctime != st.st_mtime) || (st.st_ctime != st.st_atime)))
    m->newly_created = false;


screen logfile.c
https://sources.debian.org/src/screen/4.9.0-4/logfile.c/?hl=130#L130

  if ((!s->st_dev && !s->st_ino) ||             /* stat failed, that's new! */
      !s->st_nlink ||                           /* red alert: file unlinked */
      (s->st_size < o.st_size) ||               /*           file truncated */
      (s->st_mtime != o.st_mtime) ||            /*            file modified */
      ((s->st_ctime != o.st_ctime) &&           /*     file changed (moved) */
       !(s->st_mtime == s->st_ctime &&          /*  and it was not a change */
         o.st_ctime < s->st_ctime)))            /* due to delayed nfs write */
  {

nemo libnemo-private/nemo-vfs-file.c
https://sources.debian.org/src/nemo/5.6.5-1/libnemo-private/nemo-vfs-file.c/?hl=344#L344

		/* mtime is when the contents changed; ctime is when the
		 * contents or the permissions (inc. owner/group) changed.
		 * So we can only know when the permissions changed if mtime
		 * and ctime are different.
		 */
		if (file->details->mtime == file->details->ctime) {
			return FALSE;
		}


While looking for more examples, I found a perl test that seems to suggest
that at least Solaris, AFS, AmigaOS, DragonFly BSD do as you suggest:
https://sources.debian.org/src/perl/5.36.0-7/t/op/stat.t/?hl=158#L140


Thanks

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists