[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
The above script of @jdstrand (comment #22) could be automated by a service. The basic is to create the file just after snapd.service has deleted it. Create the service in /usr/share/jehon/etc/systemd/system/lp1849753.service: [Unit] Description=Fix the App Armor profile for nodejs Documentation=https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/comments/22 Requires=snapd.service After=snapd.service snapd.apparmor.service PartOf=snapd.service [Service] Type=oneshot ExecStart= RemainAfterExit=yes [Install] WantedBy=default.target I am not 100% sure it does work in all cases, but worth a try -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
It is changing a section (the file /var/lib/snapd/apparmor/snap- confine/lp1849753) used by the snap apparmor profiles and then reloading apparmor profiles into the kernel. This does a live replacement of policy, so processes that are already confined will gain the new permissions as well as new processes. There is No transfer of ownership. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
Thanks for the workaround! Can you explain in brief how's working? Is it like temporarily transferring the ownership of the process? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
FYI, if people need to workaround this to get real work done, you can
add something like this to your bashrc:
snap_workaround() {
fn="/var/lib/snapd/apparmor/snap-confine/lp1849753"
test -e "$fn" && return
tmpfn=$(mktemp)
cat > "$tmpfn"
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
Possibly related issue: https://github.com/nodejs/node/issues/37982 ** Bug watch added: github.com/nodejs/node/issues #37982 https://github.com/nodejs/node/issues/37982 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
** Changed in: snapd (Ubuntu) Assignee: (unassigned) => Ian Johnson (anonymouse67) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
There is a RFC PR from Jamie up here: https://github.com/snapcore/snapd/pull/10029. We (snapd team) will try to pick this up and get it merged when we have some time (hopefully soon). ** Changed in: snapd (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
I should note that this only requires object delegation in apparmor, which is a subset of the full delegation work and will land first. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
In response to Jamie's question in #12 the no answer is no. Delegation works because it allows a subject with explicit access to an object to delegate that access to another. An important part of delegation is that it is not just delegating the object but inheritance and passing of the object is controlled beyond the initial passage of the object. One of the problems with most traditional capability systems is they don't correctly allow control of the inherited object which has proved to be problematic and also does not map well back to a type system. Allowing for an fd_inherit rule breaks the inheritance control in apparmor's delegation model. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
>> An alternative without modifying snap-confine would be to have two >> snap-confine profiles, one for >> strict and one for classic, and adjust the classic template to transition to >> the classic >> snap-confine template which has rules allowing 'rw' access to files and >> 'unix' for sockets. > > To me this sounds like the easier of the two approaches - can you outline any > particular > (dis)advantages to either approach? A pro for modifying snap confine means that it can still run under a restricted profile after it performs aa_change_profile(). The con is there is a short period when it isn't running under confinement. Without the investigation, it is not clear to me that the modification will achieve the objective of avoiding the file_inherit. The code changes to snap-confine would not be significant. A pro for using a different template is that it requires no code changes and is less complex. A con is that the snap-confine policy is weakened when a classic snap executes another snap. In addition to a lessening of hardening around snap-confine, it is more difficult to reason about the confinement of snap-confine. Considering that snap-confine is designed to be secure and not dependent on apparmor for its security, it is probably best to use the two-profile approach and make no code changes. This introduces no changes on systems with no classic snaps installed. While this will weaken the hardening of the safety net, there is nothing saying that we have to have a totally wide open policy for the snap-confine under classic. Eg, while we might have a wide 'rw' rules, we don't need 'x' or 'm' rules and we can use explicit deny rules for apparmor policy, libraries snap-confine uses, etc. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
> An alternative without modifying snap-confine would be to have two > snap-confine profiles, one for > strict and one for classic, and adjust the classic template to transition to > the classic > snap-confine template which has rules allowing 'rw' access to files and > 'unix' for sockets. To me this sounds like the easier of the two approaches - can you outline any particular (dis)advantages to either approach? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
I just had a similar problem trying to call a confined app from a
classic one in Python:
subprocess.run("command", stdin=open("/file/path", "rb"))
The way around it is either reading the file into memory and feeding it in:
subprocess.run("command", input=open("/file/path", "rb").read())
Or looping over the file and writing to the process's stdin:
with subprocess.Popen("command", stdin=subprocess.PIPE) as p, \
open("/file/path", "rb") as f:
while True:
buf = f.read(8192)
if buf:
p.stdin.write(buf)
else:
break
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849753
Title:
AppArmor profile prohibits classic snap from inheriting file
descriptors
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
Since the issue is that an fd is opened by the first app running in one
profile while transitioning to the snap-confine profile, there is an
option that would 'work'.
As a POC, I installed the hello-world snap and also created a test-
classic snap (just hello-world renamed with 'confinement: classic' and
installed with --classic --dangerous). Do nothing else, I then try to
reproduce the issue:
$ test-classic.sh
bash-5.0$ exec 3<> /run/user/$(id -u)/test.fd
bash-5.0$ test-classic.env > /dev/null
bash-5.0$
I see in the logs the familiar denial:
Oct 30 13:53:24 foo kernel: audit: type=1400 audit(1572461604.648:3444):
apparmor="DENIED" operation="file_inherit"
profile="/snap/core/8039/usr/lib/snapd/snap-confine"
name="/run/user/1000/test.fd" pid=24957 comm="snap-confine"
requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
I then updated /var/lib/snapd/apparmor/profiles/snap.test-classic.sh to
have:
/usr/lib/snapd/snap-confine ix,
/snap/core/8039/usr/lib/snapd/snap-confine ix,
^mount-namespace-capture-helper (complain) {
file,
unix,
signal,
}
and tried again:
$ test-classic.sh
bash-5.0$ exec 3<> /run/user/$(id -u)/test.fd
bash-5.0$ test-classic.env > /dev/null
bash-5.0$
and I observe in the logs there is no file_inherit denial.
This 'works' because the profile that snap-confine is running under is
the same as the classic snap and therefore has all the same accesses
that the snap does (I could've chosen the special 'unconfined', but
snap-confine will fail to run in that case).
Interestingly, if I run 'hello-world' from the classic snap:
$ test-classic.sh
bash-5.0$ exec 3<> /run/user/$(id -u)/test.fd
bash-5.0$ test-classic.env > /dev/null
bash-5.0$ hello-world.sh
bash-4.3$ cat /proc/self/fd/3
cat: /proc/self/fd/3: Permission denied
hello-world correctly gets the denials (first is inherit, 2nd
/apparmor/.null is how apparmor handles the access to the failed inherit
fd):
Oct 30 14:20:44 foo kernel: audit: type=1400 audit(1572463244.359:3449):
apparmor="DENIED" operation="file_inherit" profile="snap.hello-world.sh"
name="/run/user/1000/test.fd" pid=26175 comm="snap-exec" requested_mask="wr"
denied_mask="wr" fsuid=1000 ouid=1000
Oct 30 14:21:56 foo kernel: audit: type=1400 audit(1572463316.344:3451):
apparmor="DENIED" operation="open" profile="snap.hello-world.sh"
name="/apparmor/.null" pid=26244 comm="cat" requested_mask="r" denied_mask="r"
fsuid=1000 ouid=0
Now, I say 'works' because I don't care for how the snap-confine policy
is circumvented in the POC since a classic snap could then try to
exploit bugs in the setuid snap-confine. While one could argue that a
classic snap already has root on the system, many people will install
classic snaps that run as the user (ie, no daemons) and feel a bit
safer, but with the POC policy the snap could, running as the user, try
to exploit bugs in snap-confine to gain privileges.
There is possibly an acceptable way, but it would need to be
investigated to verify it works and for acceptable safety:
1. adjust the classic policy to use:
/usr/lib/snapd/snap-confine ix,
/snap/$SNAP_WITH_SNAPD/$SNAP_WITH_SNAPD_REVISION/usr/lib/snapd/snap-confine
ix,
2. adjust snap-confine to:
if apparmor enabled:
if unconfined:
if !change_profile(snap_confine_profile)
die("snap-confine has elevated permissions and is not confined but
should be"
The idea is, adjust the classic policy to transition to the unconfined
profile when calling snap-confine (the $SNAP_WITH_SNAPD* stuff is to
avoid conflicting x modifiers with the parser). This should allow snap-
confine to have the open fds without file_inherit denials. Then snap-
confine tries as early as possible to transition itself to the snap-
confine profile, dying if it can't. The kernel may revalidate the fds at
change_profile (needs verifying) and change_profile is not as strong as
fork/exec profile change, but might be acceptable for this case. snap-
confine would be susceptible to LD_PRELOAD issues, but because it is
setuid, secure_exec is in effect and areas in the filesystem that the
binary would honor with LD_PRELOAD are writable only by root (and if
someone runs the classic snap under sudo to circumvent this, they can
simply change the host however he/she desires).
An alternative without modifying snap-confine would be to have two snap-
confine profiles, one for strict and one for classic, and adjust the
classic template to transition to the classic snap-confine template
which has rules allowing 'rw' access to files and 'unix' for sockets.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849753
Title:
AppArmor profile prohibits classic snap from inheriting file
descriptors
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
" 1. adjust the classic policy to use: /usr/lib/snapd/snap-confine ix, /snap/$SNAP_WITH_SNAPD/$SNAP_WITH_SNAPD_REVISION/usr/lib/snapd/snap-confine ix, " This should have been: 1. adjust the classic policy to use: /usr/lib/snapd/snap-confine px -> unconfined, /snap/$SNAP_WITH_SNAPD/$SNAP_WITH_SNAPD_REVISION/usr/lib/snapd/snap-confine px -> unconfined, -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
John, I know there are plans for FD delegation and properly mediating this but I wonder if there is any use for a 'file_inherit' rule that is perhaps just very coarse and would allow inheriting the fd. It does seem like this could provide a means of sandbox escape though since a(n unprivileged) process could open something, then launch the (in this case, setuid) confined executable and snap-confine would have access to it. For the case of snap-confine, we only really need for snap-confine to pass through the fd to what it launches, not actually be able to use it ** Changed in: apparmor Status: New => Confirmed ** Changed in: apparmor Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
** Also affects: apparmor Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
> To be clear, I’m not using ‘snap run’, just the ‘node’ that snap has put in the PATH, which is /snap/bin/node (a symlink to /usr/bin/snap). Lots of applications expect to be able to run ‘node’ from the PATH, including the ‘node’ snap’s own ‘npm’, ‘npx’, ‘yarn’, and ‘yarnpkg’ scripts. Sure, node isn't calling snap run directly, but the act of calling /snap/bin/node (which is a symlink to /usr/bin/snap), correctly makes snap invoke the launcher via snap run. > If /snap/node/current/bin/node is expected to work better, then maybe it’s reasonable to ask why /snap/bin/node goes through /usr/bin/snap at all for a classic snap? Could snap just set it up as a direct symlink to /snap/node/current/bin/node and avoid this problem? We don't want snapd to do that since that would bypass the launcher entirely and even for classic snaps, we want the launcher to setup the environment and setup the process to be trackable by the system in various ways. Snaps calling their own binaries from $SNAP is the currently best supported method until we have the updates John mentioned. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
I am not familiar enough with the specifics of how snappy is setting policy to be able to answer your question atm. Whether it is possible will depend on policy. AppArmor mediation is post symlink so the policy would have to allow access to the target binary. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
Alright, so, when I asked in #5 whether symlinks for classic snaps in /snap/bin could point directly do the target binary instead of indirecting through snap and snap-confine, am I at least asking a legitimate question? Surely making a handful of symlink changes would be easier than developing a delegation extension for AppArmor. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
Yes I did, and @jdstrand did explain the situation in #4 "There is a revalidation that happens when node calls itself since it invokes snap run, which invokes snap-confine which causes the revalidation (because it is differently confined)." So there is a security boundary being crossed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
John, did you read more than three words of the report? We’re talking about a classic snap inheriting an fd from a classic snap (the same classic snap, in fact) for a file to which they should both have access (because they’re classic snaps). There can’t be information leaking across a security boundary when there’s no security boundary. And if there were a security boundary, it sure wouldn’t be a very good one if you could get around it by invoking the binary at a different path. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
This is traditional MAC behavior and is by design. Uncontrolled inheritance is an information leak/security hole. The delegation extension that @jdstrand mentioned is an extension that crosses capability systems with a type enforcement system. Marking this wishlist as it is feature development that is planned for but not yet resourced. ** Changed in: snapd (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
Marking confirmed based on the forum reports. To be clear, I’m not using ‘snap run’, just the ‘node’ that snap has put in the PATH, which is /snap/bin/node (a symlink to /usr/bin/snap). Lots of applications expect to be able to run ‘node’ from the PATH, including the ‘node’ snap’s own ‘npm’, ‘npx’, ‘yarn’, and ‘yarnpkg’ scripts. If /snap/node/current/bin/node is expected to work better, then maybe it’s reasonable to ask why /snap/bin/node goes through /usr/bin/snap at all for a classic snap? Could snap just set it up as a direct symlink to /snap/node/current/bin/node and avoid this problem? ** Changed in: snapd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
As Zygmunt said, this is a current limitation with apparmor. The problem is because both node and snap-confine are differently confined by apparmor, there is a revalidation that happens when node calls itself since it invokes snap run, which invokes snap-confine which causes the revalidation (because it is differently confined). FD delegation improvements in apparmor are planned that would allow for a better experience. A workaround could be to avoid snap run and call node from /snap/node/current/... instead of through /snap/bin/node. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
Note that this has been reported on the forum before at https://forum.snapcraft.io/t/classic-confinement-on-atom-yet-still-getting-denials/4956 and https://forum.snapcraft.io/t/snapd-2-32-breaks-live-server-installer/4597 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
So this is an existing issue that we sometimes tried to work around by granting snap-confine more permissions. This is a limitation in apparmor itself, where we cannot say that snap-confine can inherit and pass a file descriptor to another process, whatever that file may be. I had a quick look if that workaround handles /tmp/* but I couldn't see anything. Perhaps it needs to be added but I'd like to write a test first. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
