Option -f does not work with files in /tmp

[aleb]

In this Travis CI build you can see how ctags is executed three times:
https://travis-ci.org/daedaleanai/reqtraq/builds/625770261?utm_source=github_status&utm_medium=notification

First call succeeds and /home/travis/x123y456 is created fine, but if the output file is set to /tmp/x123y456 the file is not created and universal-ctags does not report any error.

$ ls -al /tmp
total 68
drwxrwxrwt 14 root   root   4096 Dec 16 16:44 .
drwxr-xr-x 24 root   root   4096 Dec 16 16:43 ..
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .font-unix
drwxrwxr-x  2 travis travis 4096 Dec 16 16:44 gimme
-rw-rw-r--  1 travis travis   71 Dec 16 16:43 hosts_127_0_0_1
-rw-rw-r--  1 travis travis  265 Dec 16 16:43 hosts_sans_127_0_0_1
-rw-rw-r--  1 travis travis  356 Dec 16 16:43 hosts.tmp
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .ICE-unix
drwx------  3 root   root   4096 Dec 16 16:43 systemd-private-c54bbfa7db224153b3e1dd926acbddbc-chrony.service-1cssYY
drwx------  3 root   root   4096 Dec 16 16:42 systemd-private-c54bbfa7db224153b3e1dd926acbddbc-haveged.service-lJlyEb
drwx------  3 root   root   4096 Dec 16 16:42 systemd-private-c54bbfa7db224153b3e1dd926acbddbc-systemd-resolved.service-PI4I4x
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .Test-unix
drwx------  2 travis travis 4096 Dec 16 16:44 tmp.JTfhBtZ43L
drwxrwxr-x  3 travis travis 4096 Dec 16 16:43 travis
drwxrwxr-x  3 travis travis 4096 Dec 16 16:43 v8-compile-cache-2000
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .X11-unix
drwxrwxrwt  2 root   root   4096 Dec 16 16:42 .XIM-unix
The command "ls -al /tmp" exited with 0.

$ universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f /home/travis/x123y456 /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
The command "universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f /home/travis/x123y456 /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1" exited with 0.

$ cat /home/travis/x123y456
!_TAG_FILE_FORMAT	2	/extended format; --format=1 will not append ;" to lines/
!_TAG_FILE_SORTED	0	/0=unsorted, 1=sorted, 2=foldcase/
!_TAG_PROGRAM_AUTHOR	Universal Ctags Team	//
!_TAG_PROGRAM_NAME	Universal Ctags	/Derived from Exuberant Ctags/
!_TAG_PROGRAM_URL	https://ctags.io/	/official site/
!_TAG_PROGRAM_VERSION	0.0.0	/9fcdb065/
!_TAG_OUTPUT_MODE	u-ctags	/u-ctags or e-ctags/
!_TAG_OUTPUT_FILESEP	slash	/slash or backslash/
getNumberOfSegments	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^uint8_t System::getNumberOfSegments() {$/;"	line:14
getSegment	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^const PcieSegment *System::getSegment(uint8_t i) {$/;"	line:20
enumerateObjects	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^void enumerateObjects() {$/;"	line:30
The command "cat /home/travis/x123y456" exited with 0.

$ universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f /tmp/x123y456 /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
The command "universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f /tmp/x123y456 /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1" exited with 0.

$ cat /tmp/x123y456
cat: /tmp/x123y456: No such file or directory
The command "cat /tmp/x123y456" exited with 1.

As you can see, the /tmp folder is writable, so the write error should be reported accordingly. If the stdout is redirected to the file it works fine:

$ universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f - /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1 > /tmp/x123y456
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
The command "universal-ctags --kinds-C++=f --kinds-GO=f --fields=n --recurse --sort=no -f - /home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1 > /tmp/x123y456" exited with 0.

$ cat /tmp/x123y456
getNumberOfSegments	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^uint8_t System::getNumberOfSegments() {$/;"	line:14
getSegment	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^const PcieSegment *System::getSegment(uint8_t i) {$/;"	line:20
enumerateObjects	/home/travis/gopath/src/github.com/daedaleanai/reqtraq/testdata/cproject1/a.c	/^void enumerateObjects() {$/;"	line:30

(Any reason against working around the issue by using the stdout?)

[masatake]

It looks strange — at least ctags checks the result of opening a file.
I would like to see the output of strace.
Is it possible?

[masatake]

I tried to reproduce this issue on travis in universal-ctags/ctags#2381. However, I could not.

It seems that you are using u-ctags via snap.
(daedaleanai/reqtraq@77ea066).

I guess it is snap specific issue. @tartley, could you look into this issue?

[tartley]

Thanks all. Confirmed: This is an expected symptom with the way security isolation of snaps works. Snaps cannot access the file system at all by default. We have configured some exceptions, so that our snap can access the user's home directory (with some caveats.) so I'd expect the snap will not read from /tmp.

Having spent some time understanding this situation, I'm now ready to request to the snapstore that our snap is converted to a "classic" snap, which DOES have access to the full filesystem. Thanks for the prod, I'll do it today, and report back here...

[tartley]

@aleb Oh, and yes, working around the problem by redirecting stdout has no downsides, as far as I know, if that works for you.

[aleb]

I remember reading on https://snapcraft.io/universal-ctags about such a limitation, but I forgot about it, thinking I'll notice an error when I get to using it.

Probably snap allows using /tmp but backs it with a temporary folder which is deleted when the process finishes. This explains why there is no error..

Thanks for the fast investigation!

[tartley]

FYI, I've asked snapstore if we can change our snap to 'classic' confinement. See the link I posted in a comment on an older issue about this: #4 (comment)

[aleb]

If that is not accepted by snap, consider error-ing if the output file is in /tmp when running as ctags-snap.

[tartley]

I just realized: universal-ctags is probably not outputting any error when it fails to write to /tmp because it is succeeding in writing to some other "/snap/tmp" directory, or maybe some "tmp" dir that is snap specific. So it's going to be hard for it to detect this scenario and output an error message.

For one thing, I can probably fix it so that our snap doesn't get its "/tmp" directory mapped elsewhere. That won't fix all classes of problems like this, but at least it will mean users can use "/tmp".