non-snap version of FF under Ubuntu 22.04?

[Volker Wysk]

Am Sonntag, dem 30.04.2023 um 17:45 +0200 schrieb Oliver Grawert:
> hi,
> Am Samstag, dem 29.04.2023 um 17:39 +0200 schrieb Volker Wysk:
> > ? My dad,
> > for example, likes to save HTML pages to disk. It's under the home
> > directory, so this works, but wanting to save them somewhere else
> > (such as
> > under /usr/local) isn't that far-fetched.
> 
> how would he do that unless he runs his firefox as root he will by
> default not have write permissions to anyting in /usr ?

Acquiring write permissions, or ownership, of things somewhere under
/usr/local isn't far-fetched at all. You don't have by default, but you can
easily acquire them, when you have root-access.

In my case, I often have the ownership of things in /usr/local. Especially
in /usr/local/src. For instace, I have a markdown-encoded README.md, and
compile it to READLE.html. That done, we right away have a case where
Firefox refuses to work.

> > > i agree it might be a pain for advanced users or developers but for
> > > the
> > > great majority of the non-technical average user it simply
> > > functions as
> > > intended ... 
> > > 
> > > for us others, there are ways around it (like bind mounting dirs
> > > into
> > > your home, using --devmode to drop confinement or simply making
> > > sure
> > > all your html docs end up in a pre-defined writable location), 
> > 
> > I'd rather use --classic than --devmode.
> 
> classic snaps are a completely different thing and cause *a lot* of
> extra work since they need a dedicated review by the security team
> (i.e. see [1]) ... 
> 
> there were several attempts in the past by canonical to allow debs from
> third parties to be uploaded to the archive (remember the "canonical-
> partners repo ?), they all failed due to the massive delays the
> required security (and for debs also packaging) reviews caused.
> an upload you as an external user did could sit there for a full
> release cycle until somoene found the time to review it.
> 
> this is btw one of the reasons for snaps to exist, they establish clear
> interface rules in their strict confinement that make manual reviews
> obsolete to a certain extend and allow everyone to "just upload"
> software they want to release without being able to harm your host
> system by design ... 
> 
> classic snaps are the exception here and are limited to a set of
> software that simply can not exist/be functional in strict confinement
> (IDEs, shells, compilers, editors, i.e. software that needs access to
> the systems header files and libs for building stuff). making a browser
> classic completely defeats the purpose here ...

Hmm... I didn't know this.

> 
> > 
> > > i know
> > > this is not ideal but after all it protects the masses and i can be
> > > sure i wont have to fix my moms PC due to a malicions website that
> > > utilized some hidden bug in the browser to do any harm to her
> > > install.
> > 
> > I like the protection from malicious websites, which you've
> > described. So
> > I'll continue to use Brave when (and ONLY when) Firefox refuses to
> > display a
> > file. 
> > 
> > But it would be better if the directory restrictions could be adapted
> > to the
> > needs. I've googled for that, but couldn't find any way. It looks
> > like the
> > snap would have to repackaged in order to accomplish this.
> 
> yes, this is true, you could add a system-files interface that gives
> pretty broad access (i.e. to all of /usr), but such things would have
> to happen at build time and system-files interfaces go into manual
> review by the security team on upload, who would deny such a broad
> access anyway.

I don't want to upload it. I just thought adding an allowed path locally
might be feasible.

Cheers,
Volker 

> 
> ciao
> 	oli
> 
> [1] https://forum.snapcraft.io/c/store-requests/19

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20230430/df6cc3f6/attachment.sig>