Date: Fri, 07 Jul 2023 06:50:40 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Seth Arnold <seth.arnold@...onical.com>
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 Thu, 2023-07-06 at 21:02 +0000, Seth Arnold wrote:
> 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:
> 

Thanks for looking into this!

To be clear, POSIX doesn't require that _different_ inodes ever be set
to the same timestamp value. IOW, it certainly doesn't require that the
source and target directories on a rename() end up with the exact same
timestamp value.

Granted, POSIX is rather vague on timestamps in general, but most of the
examples below involve comparing different timestamps on the _same_
inode.


> 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;
> 

This should be fine with this patchset. Note that this is comparing
a/c/mtime on the same inode, and our usual pattern on inode
instantiation is:

    inode->i_atime = inode->i_mtime = inode_set_ctime_current(inode);

...which should result in all of inode's timestamps being synchronized.

> 
> 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;
> 

Ditto here.

> 
> 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 */
>   {
> 

This one is really weird. You have two different struct stat's, "o" and
"s". I assume though that these should be stat values from the same
inode, because otherwise this comparison would make no sense:

      ((s->st_ctime != o.st_ctime) &&           /*     file changed (moved) */

In general, we can never contrive to ensure that the ctime of two
different inodes are the same, since that is always set by the kernel to
the current time, and you'd have to ensure that they were created within
the same jiffy (at least with today's code).

> 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;
> 		}
> 

Ditto here with the first examples. This involves comparing timestamps
on the same inode, which should be fine.

> 
> 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
> 

(I kinda miss Perl. I wrote a bunch of stuff in it in the 90's and early
naughties)

I think this test is supposed to be testing whether the mtime changes on
link() ?

-----------------8<----------------
    my($nlink, $mtime, $ctime) = (stat($tmpfile))[$NLINK, $MTIME, $CTIME];

[...]


        skip "Solaris tmpfs has different mtime/ctime link semantics", 2
                                     if $Is_Solaris and $cwd =~ m#^/tmp# and
                                        $mtime && $mtime == $ctime;
-----------------8<----------------

...again, I think this would be ok too since it's just comparing the
mtime and ctime of the same inode. Granted this is a Solaris-specific
test, but Linux would be fine here too.

So in conclusion, I don't think this patchset will cause problems with
any of the above code.
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists