Re:Snap, Flatpak and AppImage, package formats compared
by gcb0 on Sunday October 14, 2018 @08:20PM
(#18216453)
wait, "run without sandbox" is a pro-feature?!
[ Parent
| on HN ]
Re:Snap, Flatpak and AppImage, package formats compared
by StavrosK on Sunday October 14, 2018 @08:43PM
(#18216563)
That you have the option to, for applications that won't work without full access? Yes, definitely. I don't want my format to say "well this file manager application needs to access your filesystem so it's not available for your OS because your packaging format doesn't allow us to run unsandboxed, good luck".
Re:Snap, Flatpak and AppImage, package formats compared
by gcb0 on Monday October 15, 2018 @10:39AM
(#18220033)
I assumed the goal of those systems was for end users with no system or programming knowledge. hability to escape sandbox will only cause pain and security holes, while serving one or two advanced users.
Re:Snap, Flatpak and AppImage, package formats compared
by StavrosK on Monday October 15, 2018 @10:46AM
(#18220102)
So? Just don't allow the app to escape the sandbox.
Re:Snap, Flatpak and AppImage, package formats compared
by jhanschoo on Sunday October 14, 2018 @09:30PM
(#18216770)
Do you mean pro-feature as in it's a good feature or as in (as with the case for snaps) allowed outside of dev-mode only for paying customers of Canonical?
Re:Snap, Flatpak and AppImage, package formats compared
by seenitall on Monday October 15, 2018 @08:06AM
(#18219011)
Evidence? I don’t think that’s the case. There are plenty of non-commercial snaps with system access, it’s really a question of the nature of the snap. You would want something like Puppet to be able to read and write files all over the system, so the snap declaration and metadata needs to say that. I think the only interaction with Canonical is that they need to review snaps which do have filesystem access to check that it makes sense and ty to spot Trojan horse apps being published that way. It’s not perfect but it’s sensible.