I am not exactly sure, where the root of my problem lies. Sorry, if it turns out, it is not in sys-apps/sandbox. We have an internal ebuild, that unpacks a gentoo-install-image with unsquashfs, modifies some things and repacks it. Since upgrading sys-fs/squashfs-tools from 4.5.1-r1 to 4.6.1 (changes a function call from utimensat to lutimes), we get access violations from the sandbox: * ACCESS DENIED: lutimes: /var/tmp/portage/app-admin/install-image-20230604.170201/work/squash/usr/x86_64-pc-linux-gnu/lib/ldscripts create_inode: failed to set time on squash/usr/x86_64-pc-linux-gnu/lib/ldscripts, because Permission denied F: lutimes S: deny P: squash/usr/x86_64-pc-linux-gnu/lib/ldscripts A: /var/tmp/portage/app-admin/install-image-20230604.170201/work/squash/usr/x86_64-pc-linux-gnu/lib/ldscripts R: /usr/lib64/binutils/x86_64-pc-linux-gnu/2.39/ldscripts C: unsquashfs -d squash iso/image.squashfs So the access is violated because of the target of the symlink, but the target shouldn't matter for lutimes: lutimes() changes the access and modification times of a file in the same way as utimes(2), with the difference that if filename refers to a symbolic link, then the link is not dereferenced: instead, the timestamps of the symbolic link are changed. Therefore I think unsquashfs uses lutimes correctly and the sandbox is wrong in blocking this function call. Or am I missing something? Reproducible: Always
Understand this might be a bit tricky, but any chance you could try extract some minimal reproducer?
Should be possible. Will try on monday and report back. Have a nice weekend, so far. :)
To reproduce, try (as normal user): mkdir image-in ln -s /etc/conf.d/hostname image-in/test-link mksquashfs image-in image.squashfs sandbox unsquashfs -d image-out image.squashfs The last command produces following output: Parallel unsquashfs: Using 12 processors 1 inodes (0 blocks) to write * ACCESS DENIED: lutimes: /tmp/sandbox-test/image-out/test-link create_inode: failed to set time on image-out/test-link, because Permission denied [=====================================================================================================================================|] 1/1 100% created 0 files created 1 directory created 1 symlink created 0 devices created 0 fifos created 0 sockets created 0 hardlinks * ----------------------- SANDBOX ACCESS VIOLATION SUMMARY ----------------------- * LOG FILE: "/tmp/sandbox-10146.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: lutimes S: deny P: image-out/test-link A: /tmp/sandbox-test/image-out/test-link R: /etc/conf.d/hostname C: unsquashfs -d image-out image.squashfs * --------------------------------------------------------------------------------
It looks like utimensat is also treated incorrectly. % readlink mylink /etc/hostname % sandbox touch -h mylink * ACCESS DENIED: utimensat: /data/floppym/mylink touch: setting times of 'mylink': Permission denied * ----------------------- SANDBOX ACCESS VIOLATION SUMMARY ----------------------- * LOG FILE: "/var/log/sandbox/sandbox-12591.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: utimensat S: deny P: mylink A: /data/floppym/mylink R: /data/floppym/mylink C: touch -h mylink * --------------------------------------------------------------------------------
(In reply to Mike Gilbert from comment #4) I take that back; after adding /data/floppym to SANDBOX_WRITE, the above test works fine.
Simple reproducer: % cat lutimes.c #include <stdio.h> #include <stdlib.h> #include <sys/time.h> int main(int argc, char **argv) { if (argc < 2) return 1; if (lutimes(argv[1], NULL)) { perror("lutimes"); return 1; } return 0; }
Looks like lutimes was missed when populating the symlink_func function. https://github.com/gentoo/sandbox/pull/6
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=cdc89a00ac0bc3170d4ca7bfc77bc2572ce076b0 commit cdc89a00ac0bc3170d4ca7bfc77bc2572ce076b0 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-06-12 14:58:39 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-06-12 16:00:04 +0000 libsandbox: add lutimes to symlink_func lutimes operates on symlinks, so we should not check for access against the symlink target. Bug: https://bugs.gentoo.org/908105 Signed-off-by: Mike Gilbert <floppym@gentoo.org> libsandbox/libsandbox.c | 1 + tests/lutimes-1.sh | 9 +++++++++ tests/lutimes.at | 1 + 3 files changed, 11 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f3b8deed4484e2c2ee8c90c75e71c56ea3570405 commit f3b8deed4484e2c2ee8c90c75e71c56ea3570405 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-06-13 19:07:25 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-06-13 19:07:34 +0000 sys-apps/sandbox: add 2.31 Closes: https://bugs.gentoo.org/908105 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/sandbox/Manifest | 1 + sys-apps/sandbox/sandbox-2.31.ebuild | 64 ++++++++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+)
I confirm, that with sandbox-2.31 my ebuild works again as expected. Thanks for your quick support. :)
