Bug 756309

clone to track this issue on rhel5 kernel

+++ This bug was initially created as a clone of Bug #749117 +++

Description of problem:
In an append only dir, a open(2) call without O_RDONLY and O_APPEND will return -EPERM, but after the call new file is created.

Version-Release number of selected component (if applicable):
kernel-2.6.32-211.el6

How reproducible:
100%

Steps to Reproduce:
1. mkdir /mnt/ext4/append-only
2. chattr +a /mnt/ext4/append-only
3. ./test /mnt/ext4/append-only/testfile (touch /mnt/ext4/append-only/testfile will also work, but touch won't return error, you have to strace touch and search for open, it returns -EPERM)

# cat test.c
#include <stdio.h>
#include <sys/types.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <errno.h>

int main(int argc, char *argv[])
{
        int fd;
        fd = open(argv[1], O_RDWR|O_CREAT, 0666);
        if (fd == -1)
                perror("open failed");
        exit(errno);
}
  
Actual results:
[root@fstest xfstests]# mkdir -p /mnt/ext4/append-only
[root@fstest xfstests]# chattr +a /mnt/ext4/append-only
[root@fstest xfstests]# lsattr /mnt/ext4/
--------------- /mnt/ext4/lost+found
-----a-------e- /mnt/ext4/append-only
[root@fstest xfstests]# ./test /mnt/ext4/append-only/testfile
open failed: Operation not permitted
[root@fstest xfstests]# ls -l /mnt/ext4/append-only/testfile
-rw-r--r--. 1 root root 0 Oct 26 16:07 /mnt/ext4/append-only/testfile
[root@fstest xfstests]# lsattr /mnt/ext4/append-only/testfile
-----a-------e- /mnt/ext4/append-only/testfile

Expected results:
open(2) return success or new file is not created at all

Additional info:
xfs will create new file with no problem
btrfs will fail too

Not sure if it's really a bug, but some kind of inconsistent

--- Additional comment from pm-rhel on 2011-10-26 04:52:49 EDT ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from eguan on 2011-10-26 05:02:26 EDT ---

I found this by xfstests 079

Running test 079
#! /bin/bash
# FS QA Test No. 079
#
# Run the t_immutable test program for immutable/append-only files.
#
#-----------------------------------------------------------------------
# Copyright (c) 2000-2003 Silicon Graphics, Inc.  All Rights Reserved.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
FSTYP         -- ext4   
PLATFORM      -- Linux/x86_64 fstest 2.6.32-212.el6.x86_64
MKFS_OPTIONS  -- -b 4096 /dev/sda6
MOUNT_OPTIONS -- -o acl,user_xattr -o context=system_u:object_r:nfs_t:s0 /dev/sda6 /mnt/testarea/scratch

079 1s ... - output mismatch (see 079.out.bad)
--- 079.out     2011-10-20 19:11:39.000000000 +0800
+++ 079.out.bad 2011-10-26 15:13:05.160835493 +0800
@@ -1,7 +1,11 @@
 QA output created by 079
 *** starting up
+open(/mnt/testarea/scratch/079/append-only.d/newfile-0, O_RDWR|O_CREAT, 0666) failed: Operation not permitted
+open(/mnt/testarea/scratch/079/append-only.d/newdir-0/newfile-0, O_RDWR|O_CREAT, 0666) failed: Operation not permitted
+chmod(/mnt/testarea/scratch/079/append-only.d/newdir-0/newfile-0, 0700) failed: Operation not permitted
+chown(/mnt/testarea/scratch/079/append-only.d/newdir-0/newfile-0, 1, 1) failed: Operation not permitted
 testing immutable...PASS.
-testing append-only...PASS.
-testing immutable as non-root...PASS.
-testing append-only as non-root...PASS.
+testing append-only...FAILED! (4 tests failed)
 *** cleaning up
+rm: cannot remove `/mnt/testarea/scratch/079/append-only.d/newdir-0/newfile-0': Operation not permitted
+rm: cannot remove `/mnt/testarea/scratch/079/append-only.d/newfile-0': Operation not permitted

After some digging, it's because newly created file on extN inherits inode flags from parent directory(ext4_new_inode()), so new inode created in append-only directory has S_APPEND flag set, may_open() called by __open_namei_create checks that flag then returns -EPERM, but at that time the new inode is already created.

It seems xfs inode doesn't inherit APPEND flag from its parent dir, so xfs can pass 079

We can make extN the same behaviour as xfs(don't inherit APPEND flag), or add checking for APPEND in extN_new_inode before really allocating new inode?

--- Additional comment from rwheeler on 2011-10-28 01:31:35 EDT ---

This would be an upstream discussion I think.

--- Additional comment from eguan on 2011-10-29 21:33:19 EDT ---

Seems upstream prefers masking out append and immutable bits from EXTN_FL_INHERITED

http://permalink.gmane.org/gmane.comp.file-systems.ext4/27277