checking for iconv... yes checking for working iconv... yes checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking if umount supports --fake --no-canonicalize... ACCESS DENIED open_wr: /etc/mtab configure: creating ./config.status config.status: creating fuse.pc config.status: creating Makefile config.status: creating lib/Makefile config.status: creating util/Makefile config.status: creating example/Makefile config.status: creating include/Makefile config.status: creating doc/Makefile config.status: creating include/config.h config.status: executing depfiles commands config.status: executing libtool commands configure: WARNING: ****************************************************************** * Please install util-linux version 2.18 or later which supports * * --fake and --no-canonicalize options in mount and umount * ****************************************************************** >>> Source configured. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-4442.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: open_wr S: deny P: /etc/mtab A: /etc/mtab R: /etc/mtab C: umount --fake --no-canonicalize F: open_wr S: deny P: /run/mount/utab A: /run/mount/utab R: /run/mount/utab C: umount --fake --no-canonicalize F: open_wr S: deny P: /etc/mtab A: /etc/mtab R: /etc/mtab C: umount --fake --no-canonicalize -------------------------------------------------------------------------------- Reproducible: Always
"Please install util-linux version 2.18 or later which supports..." What does 'emerge -pv util-linux' output?
I have the same problem. My installed version of util-linux is 2.22, but when I emerge sys-fs/fuse-2.9.1-r1 it also show the errors above.
The problem seems to be that the configure scripts runs umount to try to determine if the command accepts the --fake --no-canonicalize arguments. Running umount --fake --no-canonicalize without arguments seems to try to open /run/mount/utab (probably because, according to the man page, the --fake argument "can be used to remove entries from /etc/mtab that were unmounted earlier with the -n option."), and hence the access violation.
Created attachment 326582 [details, diff] Don't check for umount at configure time (Sorry; sent report before finishing). According to the man page, therefore, the umount command with the --fake argument can modify the filesystem, so running it at configure time seems to be unwise. Maybe a bug report should be filed in fuse upstream. Meanwhile, and since we can guarantee that we have the required version of util-linux, we can workaround the problem with the attached patch to the ebuild.
(In reply to comment #3) > The problem seems to be that the configure scripts runs umount to try to > determine if the command accepts the --fake --no-canonicalize arguments. > Running umount --fake --no-canonicalize without arguments seems to try to > open /run/mount/utab (probably because, according to the man page, the > --fake argument "can be used to remove entries from /etc/mtab that were > unmounted earlier with the -n option."), and hence the access violation. Correct, I agree.
(In reply to comment #4) > Created attachment 326582 [details, diff] [details, diff] > Don't check for umount at configure time > > (Sorry; sent report before finishing). > > According to the man page, therefore, the umount command with the --fake > argument can modify the filesystem, so running it at configure time seems to > be unwise. Maybe a bug report should be filed in fuse upstream. > > Meanwhile, and since we can guarantee that we have the required version of > util-linux, we can workaround the problem with the attached patch to the > ebuild. Disabling the check making it always true correctly workarounds the problem. The final solution should be done upstreams. Other distros will also face problems like this due to their sandboxing approach.
Another workaround, probably easier, from bug #437568: just install sys-apps/sandbox-2.6, and then you can install sys-fs/fuse-2.9.1-r1 without sandbox violations. There is a warning about ACCESS DENIED, but the emerge finishes correctly.
It seems that this bug only exists on sys-fs/fuse-2.9.1-r1 with unstable util-linux-2.22* and stable sandbox-2.5, is this correct?
I'm not able to reproduce the bug with util-linux-2.22.1 and stable sandbox-2.6.
sandbox-2.6 isn't stable, though. Downgrade to the actual stable sandbox-2.5 and that is where the bug appears.
(In reply to comment #10) > sandbox-2.6 isn't stable, though. Neither is util-linux 2.22. Can you reproduce the bug with sandbox-2.5 and util-linux-2.21*? If you can, then there is a bug. If you cannot, then it's our fault for mixing stable and unstable packages, and the bug should be closed. > Downgrade to the actual stable sandbox-2.5 and that is where the bug appears. I don't think there is actually a bug. If you are running unstable util-linux, there is no reason to expect for stable sandbox to work with it.
It is still a bug. This will become an even bigger problem if util-linux-2.22 goes stable without sandbox-2.6 going stable also. I just wanted to confirm that this was ONLY affecting users who are mixing util-linux-2.22 with sandbox-2.5, I still believe this is the case.
have the exact problem with: sys-apps/util-linux-2.22.1 sys-apps/sandbox-2.5 sys-fs/fuse- available: 2.9.1-r1 installed: 2.8.6 unstable util-linux was solution to an earlier block with: sys-apps/util-linux-2.22.1 sys-apps/sandbox-2.6 sys-fs/fuse- available: 2.9.1-r1 installed: 2.8.6
(In reply to comment #7) > Another workaround, probably easier, from bug #437568: just install > sys-apps/sandbox-2.6, and then you can install sys-fs/fuse-2.9.1-r1 without > sandbox violations. There is a warning about ACCESS DENIED, but the emerge > finishes correctly. Unfortunately, your workaround does not work for me. I have Linux Debian, and there is no such a thing as "sandbox-2.6". If I am wrong, please tell me the truth.
(In reply to comment #14) > (In reply to comment #7) > > Another workaround, probably easier, from bug #437568: just install > > sys-apps/sandbox-2.6, and then you can install sys-fs/fuse-2.9.1-r1 without > > sandbox violations. There is a warning about ACCESS DENIED, but the emerge > > finishes correctly. > > Unfortunately, your workaround does not work for me. > I have Linux Debian, and there is no such a thing as "sandbox-2.6". > If I am wrong, please tell me the truth. This Bug Tracker system is focused on a distribution called Gentoo. You are using Debian. Each distribution has its own way of sandboxing. You should probably first try to seek a solution amongst Debian folks.
if newer sandbox issues the warning but doesn't abort, that's a bug in sandbox would probably be better to have the configure script run `umount --help` and grep the output
(In reply to comment #16) > if newer sandbox issues the warning but doesn't abort, that's a bug in > sandbox > > would probably be better to have the configure script run `umount --help` > and grep the output Totally agree on both the sandbox behavior being buggy and about the configure script as well.
Happens also with sys-fs/fuse-2.9.2 and sys-apps/util-linux-2.22.1 and sys-apps/sandbox-2.6.
As a workaround, fuse can be emerged with FEATURES=userpriv
(In reply to comment #16) > if newer sandbox issues the warning but doesn't abort, that's a bug in > sandbox > > would probably be better to have the configure script run `umount --help` > and grep the output That doesn't help: # sandbox umount --help * ACCESS DENIED: open_wr: /run/mount/utab Basically, any attempt to execute recent versions of umount results in umount testing whether utab and mtab files are writable, and it tests whether they are writable by calling open(filename, O_RDWR) :/
*** Bug 460022 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > It is still a bug. This will become an even bigger problem if > util-linux-2.22 goes stable without sandbox-2.6 going stable also. FYI this is current reality now, sys-fs/fuse will not build on stable.
Latest Version of Sandbox (Sandbox-2.6) Bypasses the error checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking if umount supports --fake --no-canonicalize... * ACCESS DENIED: open_wr: /etc/mtab * ACCESS DENIED: open_wr: /run/mount/utab * ACCESS DENIED: open_wr: /etc/mtab * ACCESS DENIED: open_wr: /run/mount/utab configure: creating ./config.status Fuse-2.9.1-r1 and Fuse 2.9.2 compile successfully on Sandbox-2.6
(In reply to comment #22) > (In reply to comment #12) > > It is still a bug. This will become an even bigger problem if > > util-linux-2.22 goes stable without sandbox-2.6 going stable also. > > FYI this is current reality now, sys-fs/fuse will not build on stable. Then please mask fuse, mark it unstable, please. This will prevent pulling fuse into world update.
(In reply to comment #23) > Latest Version of Sandbox (Sandbox-2.6) > > Bypasses the error > > checking for iconv declaration... > extern size_t iconv (iconv_t cd, char * *inbuf, size_t > *inbytesleft, char * *outbuf, size_t *outbytesleft); > checking if umount supports --fake --no-canonicalize... * ACCESS DENIED: > open_wr: /etc/mtab > * ACCESS DENIED: open_wr: /run/mount/utab > * ACCESS DENIED: open_wr: /etc/mtab > * ACCESS DENIED: open_wr: /run/mount/utab > configure: creating ./config.status > > Fuse-2.9.1-r1 and Fuse 2.9.2 compile successfully on Sandbox-2.6 That is a problem of sandbox-2.6. See comment #16: https://bugs.gentoo.org/show_bug.cgi?id=438250#c16
okay, workaround for fuse is in tree but since it has been concluded this is a bug in sandbox, reassigning to sandbox maintainers
I just unmasked fuse-2.9.2 and tried to emerge it: Issue is gone, it works now. Thanks for that. But what nobody tried here: fuse-2.9.1-r1, currently marked as the latest stable version, is also (and still) affected by this issue. echo "sys-fs/fuse" >> /etc/portage/package.keywords helped me so far but I think you should either apply your change to the current stable version, too or mark fuse-2.9.2 as stable.
(In reply to comment #27) > I just unmasked fuse-2.9.2 and tried to emerge it: Issue is gone, it works > now. Thanks for that. But what nobody tried here: fuse-2.9.1-r1, currently > marked as the latest stable version, is also (and still) affected by this > issue. > > echo "sys-fs/fuse" >> /etc/portage/package.keywords helped me so far but I > think you should either apply your change to the current stable version, too > or mark fuse-2.9.2 as stable. I propose using the Bugzilla's Search feature (to find bug 460564)
(In reply to comment #16) the missing abort is fixed in sandbox-2.6-r1 the fact that it aborts in the first place isn't a bug in sandbox. fuse ran a command that tried to open paths for writing that it shouldn't have.
Looks like affected versions of fuse are long gone.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8a970396fca7aca2d5a761b8e7a8242f1eef14c9 commit 8a970396fca7aca2d5a761b8e7a8242f1eef14c9 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-08-03 22:19:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-03 22:19:06 +0000 sys-fs/fuse: fix build with glibc 2.34 Backporting the same patch which is now upstream, converted to patches for autotools changes rather than sed for further changes. Bug: https://bugs.gentoo.org/438250 Closes: https://bugs.gentoo.org/803923 Signed-off-by: Sam James <sam@gentoo.org> .../files/fuse-2.9.9-avoid-calling-umount.patch | 38 ++++++++++++++ .../files/fuse-2.9.9-closefrom-glibc-2-34.patch | 60 ++++++++++++++++++++++ sys-fs/fuse/fuse-2.9.9-r1.ebuild | 22 ++++---- 3 files changed, 110 insertions(+), 10 deletions(-)