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

Bug #1581310 reported by Michael Nelson on 2016-05-13
This bug affects 8 people
Affects Status Importance Assigned to Milestone
snapd (Ubuntu)
Jamie Strandboge

Bug Description

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/
#! /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

michael@dev-xenial2:~/dev/todo.txt⟫ todo-txt.test-sed
The fast brown fox jumped over the lazy dog
/snap/todo-txt/100001/ line 5: 11763 Bad system call sed -i.bak 's/quick/fast/' $SNAP_USER_DATA/sed-test.txt
/snap/todo-txt/100001/ 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="" 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="" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0

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

Michael Nelson (michael.nelson) wrote :

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

$ grep chown sed/execute.c -B4 -A2
      output_fd = fileno (output_file.fp);
      /* 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));
      copy_acl (input->in_file_name, input_fd,

Jamie Strandboge (jdstrand) wrote :

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.

tags: added: snapd-interface
Changed in snapd (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Jamie Strandboge (jdstrand)
Jamie Strandboge (jdstrand) wrote :


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) wrote :

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) wrote :

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.

summary: - ubuntu-core doesn't allow sed -i (fchown syscall)
+ please allow chown for calling user (eg, for files in SNAP_USER_DATA)
summary: - please allow chown for calling user (eg, for files in SNAP_USER_DATA)
+ please allow chown for calling user (eg, for files in SNAP_USER_DATA or
+ chowning to root)
Changed in snapd (Ubuntu):
importance: Medium → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers