[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1JwY3V-0006CO-Lz@pomaz-ex.szeredi.hu>
Date: Thu, 15 May 2008 09:39:13 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: viro@...IV.linux.org.uk
CC: miklos@...redi.hu, akpm@...ux-foundation.org, hch@...radead.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 08/24] vfs: immutable inode checking cleanup
> > --- linux-2.6.orig/fs/attr.c 2008-05-06 11:04:29.000000000 +0200
> > +++ linux-2.6/fs/attr.c 2008-05-06 11:04:35.000000000 +0200
> > @@ -108,6 +108,12 @@ int notify_change(struct dentry * dentry
> > struct timespec now;
> > unsigned int ia_valid = attr->ia_valid;
> >
> > + if (ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID |
> > + ATTR_ATIME_SET | ATTR_MTIME_SET)) {
> > + if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
> > + return -EPERM;
> > + }
> > +
> > now = current_fs_time(inode->i_sb);
> >
> > attr->ia_ctime = now;
> > Index: linux-2.6/fs/utimes.c
> > ===================================================================
> > --- linux-2.6.orig/fs/utimes.c 2008-05-06 11:04:29.000000000 +0200
> > +++ linux-2.6/fs/utimes.c 2008-05-06 11:04:35.000000000 +0200
> > @@ -105,10 +105,6 @@ long do_utimes(int dfd, char __user *fil
> > /* Don't worry, the checks are done in inode_change_ok() */
> > newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME;
> > if (times) {
> > - error = -EPERM;
> > - if (IS_APPEND(inode) || IS_IMMUTABLE(inode))
> > - goto mnt_drop_write_and_out;
> > -
> > if (times[0].tv_nsec == UTIME_OMIT)
> > newattrs.ia_valid &= ~ATTR_ATIME;
> > else if (times[0].tv_nsec != UTIME_NOW) {
>
> Erm... What happens if we have UTIME_NOW on both and inode is marked
> immutable? AFAICS, you've just switched from -EPERM to -EACCES.
> For append-only it's even more interesting - you go from -EPERM to
> success.
Yup. These are defensible on the ground that times == NULL should be
equivalent to UTIME_NOW on both. There's really no reason to be
stricter on the latter case.
> It might or might not be the right thing to do, and the syscall is
> new, but... Do you have an ACK from Ulrich?
No. I could CC him on these, but he's not even acking my security
patches on utimesat, so I don't have high hopes.
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists