please allow chown for calling user (eg, for files in SNAP_USER_DATA or chowning to root)

[Michael Nelson]

Similar to bug 1580018, I'm not sure if the default apparmor profile is not correct, or possibly this bug is invalid and `sed -i.bak` should be denied.

AFAICT, the issue is that sed -i.bak tries a chown syscall on the backup file in the $SNAP_USER_DATA directory, and the apparmor profile does not allow that (perhaps for good reason).

michael@dev-xenial2:~/dev/todo.txt⟫ cat /snap/todo-txt/100001/test-sed.sh
#! /bin/bash

echo "The quick brown fox jumped over the lazy dog" > $SNAP_USER_DATA/sed-test.txt
sed 's/quick/fast/' $SNAP_USER_DATA/sed-test.txt | tee $SNAP_USER_DATA/sed-output.txt
sed -i.bak 's/quick/fast/' $SNAP_USER_DATA/sed-test.txt
chown

michael@dev-xenial2:~/dev/todo.txt⟫ todo-txt.test-sed
The fast brown fox jumped over the lazy dog
/snap/todo-txt/100001/test-sed.sh: line 5: 11763 Bad system call sed -i.bak 's/quick/fast/' $SNAP_USER_DATA/sed-test.txt
/snap/todo-txt/100001/test-sed.sh: line 6: /bin/chown: Permission denied

126 michael@dev-xenial2:~/dev/todo.txt⟫ ls -l ~/snap/todo-txt/100001/
total 12
-rw-rw-r-- 1 michael michael 44 May 13 04:30 sed-output.txt
-rw-rw-r-- 1 michael michael 45 May 13 04:30 sed-test.txt
---------- 1 michael michael 44 May 13 04:30 sedwCnCDY

michael@dev-xenial2:~/dev/todo.txt⟫ dmesg -H | tail -n3
[ +39.843825] audit: type=1326 audit(1463113859.687:232): auid=1001 uid=1001 gid=1001 ses=4 pid=11763 comm="sed" exe="/bin/sed" sig=31 arch=c000003e syscall=93 compat=0 ip=0x7f8428874a77 code=0x0
[ +0.001342] audit: type=1400 audit(1463113859.691:233): apparmor="DENIED" operation="exec" profile="snap.todo-txt.test-sed" name="/bin/chown" pid=11764 comm="test-sed.sh" requested_mask="x" denied_mask="x" fsuid=1001 ouid=0
[ +0.000100] audit: type=1400 audit(1463113859.691:234): apparmor="DENIED" operation="open" profile="snap.todo-txt.test-sed" name="/bin/chown" pid=11764 comm="test-sed.sh" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0

michael@dev-xenial2:~/dev/todo.txt⟫ scmp_sys_resolver 93
fchown

[Michael Nelson (michael.nelson)]

Interestingly, sed is happy to ignore failures on fchown itself:

$ grep chown sed/execute.c -B4 -A2
      output_fd = fileno (output_file.fp);
#ifdef HAVE_FCHOWN
      /* Try to set both UID and GID, but if that fails,
         try to set only the GID. Ignore failure. */
      if (fchown (output_fd, input->st.st_uid, input->st.st_gid) == -1)
        ignore_value (fchown (output_fd, -1, input->st.st_gid));
#endif
      copy_acl (input->in_file_name, input_fd,

[Jamie Strandboge (jdstrand)]

Thank you for filing a bug. We don't allow chown atm because we don't yet have seccomp argument filtering to limit what a snap can chown to. This work is in progress and when it has landed the policy will be adjusted accordingly for chown.

[Jamie Strandboge (jdstrand)]

From https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1590720/comments/3:

"
Thank you for filing a bug. It is actually seccomp (not AppArmor) that is blocking this call. You can workaround this for now by installing with --devmode. We don't allow the chown family of syscalls at this time because that would open holes in the sandbox.

Today, you can adjust your program to not use fchown or to create a small LD_PRELOAD library that you can ship with your that implements a no-op for fchown.

Soon we will have seccomp argument filtering in our sandbox which will allow us to then, for example, allow apps to chown files to their own UID and GID, but we'd need to figure out a way to do this dynamically (perhaps the launcher could unconditionally add chown calls for the UID/GID, this needs more thought). Alternatively, the designed-but-not-yet-implemented snappy preload library could do something with chown so developers wouldn't have to.
"

[Lars Tangvald (lars-tangvald)]

The MySQL daemon will not run as root, but will drop privileges down to a specified user instead, which needs to own the files in the specified data directory.

So currently MySQL will only run on user home databases (without devmode) since we can't change ownership or users.

[Jamie Strandboge (jdstrand)]

This bug and bug #1619888 are similar but different. This bug deals with SNAP_USER_DATA and chowning to the calling user. The seccomp arg filtering feature has landed and fixing this in security policy is planned soon now that various other dev work for snappy GA is being completed.

@Lars - your comment really about adding users to the system with which snaps can then drop privileges and therefore chown files. That work is planned but needs design.

[Samuele Pedroni (pedronis)]

Jamie Strandboge is this fixed now?

[Jamie Strandboge (jdstrand)]

The bug as reported has not been fixed since we do not allow the calling user to chown to its own id. At the time of my comments, it was thought that we might allow this in the policy, but the implementation for that feature changed and we do not allow this.

Since the bug was reported, a number of things have happened:
* we allow use of the 'chown' binary in the default template
* we return EPERM rather than killing the process
* we introduced system-usernames

Today, 'sed -i' will trigger a seccomp denial in the logs, but it is non-fatal due to using EPERM in the syscall filter. Eg:

bash-4.3$ sed -i.bak 's/quick/fast/' $SNAP_USER_DATA/sed-test.txt
bash-4.3$ cat $SNAP_USER_DATA/sed-test.txt
The fast brown fox jumped over the lazy dog

This would also work with the root user. What does not work, by design, is that the calling user cannot chown to other users/groups. For this, we introduced the system-usernames feature (https://forum.snapcraft.io/t/system-usernames/13386) which allows the root user to chown files to the specified system-usernames (eg, 'snap_daemon').

As such, this bug shouldn't be marked 'Fix Released' but we can mark it Won't Fix since we addressed the shortcomings of the policy in other ways.