Redirection to file doesn't work when snap program invokes another snap program via shell

Bug #1921110 reported by Victor Gaydov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
New
Undecided
Unassigned

Bug Description

Hi!

I'm using snap 2.49.1 on Debian 10. The issue is also reproducing on snap 2.49.1 on Ubuntu 20.04 in VirtualBox.

I'm experiencing a very strange bug with, apparently, all programs installed via snap --classic.

If I run program FOO, installed from snapcraft, and it runs a shell, which in turn runs program BAR, also installed from snapcraft, and BAR's output is redirected to a file, I always get zero exit code, but an EMPTY FILE.

If, instead of BAR, FOO runs some non-snap program, it works as expected. If FOO redirects BAR's output to cat's stdin, and redirects cat's stdout to a file, it also works as expected.

Here are some examples with "ruby" from snap:

$ sudo snap install ruby --classic
...

$ cat hello.rb
puts "hello from ruby"

GOOD:
$ /snap/bin/ruby hello.rb > out
$ cat out
hello from ruby

GOOD:
$ /snap/bin/ruby -e 'system("/snap/bin/ruby hello.rb | cat > out")'
$ cat out
hello from ruby

GOOD:
$ /snap/bin/ruby -e 'system("echo hello from shell > out")'
$ cat out
hello from shell

>>>>>>>> BAD <<<<<<<<
$ /snap/bin/ruby -e 'system("/snap/bin/ruby hello.rb > out")'
$ cat out
<nothing>

Here are similar examples with "go: from snap:

$ sudo snap install go --classic
...

$ cat hello.go
package main

import "fmt"

func main() {
    fmt.Println("hello from go")
}

$ cat exec.go
package main

import "syscall"
import "os"

func main() {
    syscall.Exec("/bin/sh", []string{"sh", "-c", os.Args[1]}, os.Environ())
}

GOOD:
$ /snap/bin/go run hello.go > out
$ cat out
hello from go

GOOD:
$ /snap/bin/go run exec.go "/snap/bin/go run hello.go | cat > out"
$ cat out
hello from go

GOOD:
$ /snap/bin/go run exec.go "echo hello from shell > out"
$ cat out
hello from shell

GOOD (non-snap go):
$ /usr/bin/go run exec.go "/usr/bin/go run hello.go > out"
$ cat out
hello from shell

>>>>>>>> BAD <<<<<<<<
$ /snap/bin/go run exec.go "/snap/bin/go run hello.go > out"
$ cat out
<nothing>

Please let me know if I can provide any further information!

Revision history for this message
Victor Gaydov (gavv42) wrote :

Fun fact: originally I faced this issue when compiling BoringSSL. I had both CMake and Go installed from snap. BoringSSL can't be built with this setup, since CMake invokes "go run file.go > file.c" for code generation during build, and it produces an empty file instead of the desired code.

For people coming from Google: if you're using snap and get strange linker errors when building BoringSSL, you're probably facing the same issue:

/usr/bin/ld: libcrypto.a(err.c.o): in function `ERR_reason_error_string':
boringssl/crypto/err/err.c:579: undefined reference to `kOpenSSLReasonValuesLen'
/usr/bin/ld: boringssl/crypto/err/err.c:578: undefined reference to `kOpenSSLReasonValues'
/usr/bin/ld: boringssl/crypto/err/err.c:578: undefined reference to `kOpenSSLReasonStringData'

Revision history for this message
Maciej Borzecki (maciek-borzecki) wrote :

Are there any AppArmor denials logged in dmesg? I suspect this may be a duplicate of #1849753.

Revision history for this message
Victor Gaydov (gavv42) wrote :

When I run:

/snap/bin/ruby -e 'system("/snap/bin/ruby hello.rb > out")'

I get this is dmesg:

[314807.422612] audit: type=1400 audit(1616588664.274:462): apparmor="DENIED" operation="file_inherit" profile="/snap/core/10908/usr/lib/snapd/snap-confine" name="/home/victor/stash/snap-bug/out" pid=19209 comm="snap-confine" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000

affects: snapcraft → snapd
Revision history for this message
Ian Johnson (anonymouse67) wrote :

The denial mentioned above indicates that this bug is a duplicate of https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.