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. ** Changed in: snapd (Ubuntu) Importance: High => Wishlist ** Changed in: snapd (Ubuntu) Status: Triaged => Won't Fix ** Changed in: snapd (Ubuntu) Assignee: Jamie Strandboge (jdstrand) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1581310 Title: please allow chown for calling user (eg, for files in SNAP_USER_DATA or chowning to root) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1581310/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
