Google Chrome 64-bit packages - [CLOSED]

[s243a]

Mike, as our resident Chrome expert, what are the limitations, if any, imposed by running google chrome with the --no-sandbox switch?

I'm not concerned about running as root with no sandboxing as I'm already containing chrome within a restricted environment anyway i.e. FatDog 8 with a Barry like containment (Xephyr, unshare, chroot with capsh (capabilities for sys_admin and chroot dropped)), so pretty much a heavily restricted 'root' - comparable to a low privilege/restricted userid that's isolated from the main FatDog X system. Providing you don't keep sensitive data/stuff within that container then that's impervious to even a zero day vulnerability. But I was wondering what limitations running with --no-sandbox might impose.

TIA.

On could always do a "run as spot", script but it's still worth discussing. On my TazPup64, I'm thinking of adding an environmental variable that determines whether the --no-sandbox is used vs "run as some restricted user".

P.S. on another thread, I mentioned your restricted containers to someone.

[Mike Walsh]

Morning, ruffers.

Hoo... Y'know, to be perfectly honest, I've never really looked into the security aspects of it. Not in anywhere near the same way that I know you yourself do, quite regularly. (And I definitely dispute the 'expert' tag. I'm a bumbler, really, although I managed to assemble all the various bits that many other folks helped with over the last few years.....without making too many mistakes. I mean, it runs..... )

I digress.

Y'see, this is where the differences between the various Chromium 'clones' begins to show through. Chromium itself, as released, will run without the sandbox, although it doesn't like it.

-----------------------------------------------

SRWare's Iron, although using the 'chrome' shared library/binary thingy (it's not a binary executable in the true sense of the word, though it's where the bulk of the program lies), will also run without the sandbox.

-----------------------------------------------

FlashPeak, with recent releases of SlimJet, have coded things so that you've got to run it as a restricted user. No arguments. Try using the --no-sandbox switch, it just won't run.

-----------------------------------------------

Google, with Chrome, have done much the same. In true Google style, though, they've enhanced the standard sandbox set-up even further so that the browser uses around 5 different sandboxes, all interacting with each other. Which in part accounts for the huge size these browsers are now ballooning into. It decidedly will not run without the sandboxing enabled, and, moreover, that sandboxing is linked into the use as a restricted user. If you don't get all the conditions just right, it simply doesn't want to know.

I don't think, for your purposes, it would make any difference that you're already running it inside a container. The 'sandboxing' is fully internal to the browser process, and if you enable the switch, it wouldn't start.

Hope that throws some light on things.....though it's far from a complete answer.


Mike.

[rufwoof]

Oooerrr! Confused now!

I'm running google chrome as root inside that container with the --no-sandbox and it runs seemingly OK. Just has a bar come up initially saying that sandbox is disabled and security/functionality is compromised.

[rufwoof]

P.S. on another thread, I mentioned your restricted containers to someone.

I have much the same set up in FatDog 8 now. What I've done for that is to have the main systems tray at the top of screen, and the containers tray at the default bottom of screen location. I set the Xephyr window to be undecorated (no title bar) and size it to 32 less height and Y offset by 32 ... so it doesn't overlay the main systems tray. That way you can activate menu's or the tray items in either the main or container quickly/easily.

The main quirks are that sometimes the mouse gets locked inside the container and you have to ctrl-shift to release it again. And you have to be aware of which windows are in which environment as you can't for instance cut from a container window and paste into a main system window.

Not so confident about spot myself. I have found it easy to elevate to root from spot in a number of Puppy's to the extent I considered it pointless in most cases. Fatdog 8 is one of the exceptions.

[Mike Walsh]

Oooerrr! Confused now!

I'm running google chrome as root inside that container with the --no-sandbox and it runs seemingly OK. Just has a bar come up initially saying that sandbox is disabled and security/functionality is compromised.

Hm. Well, that's news to me.....and something I've learnt. Under normal circumstances, it won't work for me; perhaps running inside the container has changed its ability to run without the sandbox enabled.

Can't say, mate.


Mike.

[rufwoof]

Whatever its going, with chrome just showing the puppy forum web page, all child processes spawned by chrome also have the --no-sandbox parameter. So yes does work.

Maybe because that container has cap_sys_admin and cap_sys_chroot capabilities dropped - chrome might perhaps be able to detect its not a full blown root. Running without the --no-sandbox however and it does complain/not run.

[rufwoof]

It would seem that running chrome with its sandbox requires root level chroot capabilities. Drop chroot capability and you have to use the --no-sandbox command line parameter. In a chroot container however you don't want chroot capabilities, otherwise you (or potential cracker) can just chroot out of the container.

So the choices would seem to be to either run as spot inside a container with chroot capabilities, but perhaps where spot doesn't have chroot potential, or run as root with no chroot capabilities at all.

Weighing things up, fundamentally do you put total faith in chrome's containment, and hope that spot can't elevate to root, or run chrome as root inside the Xephyr/unshare/chroot/capsh environment, with no-sandbox. Of the two the latter seems the better choice IMO, more so given recent chrome zero day bugs that potentially opened up the system. Also I have little faith in spot not being able to potentially elevate to root - potentially relatively easily, which further adds to the appeal of not permitting chroot capabilities.

In short I think Xephyr/unshare/chroot/capsh with chrome running as root with --no-sandbox is the better choice compared to trying to run chrome as spot within a container.

cd /pub
more beer

[s243a]

Mike, as our resident Chrome expert, what are the limitations, if any, imposed by running google chrome with the --no-sandbox switch?

I'm not concerned about running as root with no sandboxing as I'm already containing chrome within a restricted environment anyway i.e. FatDog 8 with a Barry like containment (Xephyr, unshare, chroot with capsh (capabilities for sys_admin and chroot dropped)), so pretty much a heavily restricted 'root' - comparable to a low privilege/restricted userid that's isolated from the main FatDog X system. Providing you don't keep sensitive data/stuff within that container then that's impervious to even a zero day vulnerability. But I was wondering what limitations running with --no-sandbox might impose.

TIA.

I noticed something weird about Opera (and possibly other chrome clones), when running with the --no-sandbox tag. On my TazPup64 I'm working on I had opera running under jwm. I exited Xorg and started LXDE. I noticed Opera was running like it had never shut down when I exited XOrg. To me this behavior is undesirable because then cntrl-alt-backspace is less likely to unfreeze the system if for some reason the system freezes.

Perhaps I can add a command to specifically kill chrome (and it's clones) in whatever script ("presumably wmexit") is called when I press cntrl-alt-backspace.

Note that, I didn't yet check to see what Opera related process might continue to run when the Xserver shuts down.

[Mike Walsh]

Evening, all.

The current stable version of Chrome - Google_Chrome-74.0.3729.108-amd64 - is now available for download, from the location referenced in post #1.

------------------------------------------------

Changes and updates in this release are as explained here, on the regular Chrome blog page.

39 security issues have been addressed since the previous release.

----------------------------------------------------

A small script, which has been placed in /usr/sbin & sym-linked into /root/Startup, now automatically runs the glib-compile-schemas compile command at boot time. Downloads/uploads, therefore, work as they should.

The 'Spot2Root' file permissions changer has also been updated. It now works with uploads as well as downloads.....as explained in an earlier post. Following an exchange of ideas & points raised via PM with mikeslr, I've added an extra line to the 'spot-to-root' module of the Permissions Changer which sits in the task-bar; when you select 'Spot-to-Root (for downloads)' in the GUI, ROX (or whatever your default file-manager happens to be) will now open on your 'Downloads' directory, ready to retrieve the newly-downloaded item.

It's also been re-written to remove the need for the intermediate 'Spot2Root' directory in /usr/share. Following some research using the Linux man pages, I've finally discovered how to move stuff from one directory to another and change permissions in the process, all in the one single line of code....

I'm steadily learning.

------------------------------------------------------------------

Credits (as usual) :-

Battleshooter - for help with the self-contained NSS libs'n'stuff several releases back.
belham2 - for cobbling together the 'launch' script that is now employed.
And further back, 01Micko (the 'head honcho'), and iguleder - both of whom have indirectly helped keep this thread going for as long as it has, with references & links.

Thanks must also go to OscarTalks and peebee, for suggestions and assistance over the last couple of years.

---------------------------------

Any issues, I'm usually kicking around somewhere on the Forums. You know how to get in touch.

Have fun!


Mike.

[albertox]

@Mike Walsh

Thank you so much Mike for keeping Chrome up to date, it's my favorite browser too. We are very lucky to have great people like you and the others in the forum who devote their free time to provide us with various software.

I don't know if this has been answered already, but I couldn't find it in search. I'm running TahrPup64 and SFS version. Chrome crashes if I try to change the downloads location. It also crashes if I set Downloads to "ask where to save", when trying to download before the choose location menu comes up.

I'm not sure if I'm doing something wrong, as I'm a newcomer to GNU/Linux, and still struggling with the technical stuff.
.

[Mike Walsh]

@ albertox:-

Umm. Mm-hm.

I always did have 'issues' with up-to-date Chrome in Tahrpup64. It's part of the reason why I switched to doing my development/packaging work in Xenialpup64.....it never gave me any problems.

Tahr64 was 666philb's very first 64-bit Puppy. Naturally, it was a learning curve, not only for him, but for the rest of us, too. By the time Xenial Xerus 16.04 LTS was released, Phil had learnt a lot of 'tricks' from his first 64-bit attempt, with the result that Xenialpup64 has just been that much smoother, and more stable, from the outset. We all learn from our mistakes.....it's how the human learning process works.

Not being funny, but I would definitely suggest upgrading to Xenialpup64. 'Trusty Tahr' went EOL on the 30th April (day before yesterday), so is now unsupported. (I mean, Puppies are in fact 'timeless', as we all know.....but even Puppies have to move on in order to be able to run newer software.)

I vaguely recall the problem in Tahr64 being something to do with the available version of GTK-3.0; newer versions wouldn't 'play nice' with the system libraries, etc (and too many things needed upgrading to make it worthwhile 'fixing').

------------------------

Try this. I assume you're trying to run the newest version I've just published, yes? If so, run

Code: Select all

/home/spot/chrome.sh

.....in the terminal, and let me have the output, please. (There'll be a lot of it; the Chromium 'clones' are incredibly 'verbose' and 'noisy' in the terminal; part of the reason is that this is where debug info comes from for the developers).


Mike.

[albertox]

Thank you Mike for your reply.

Yes, I'm currently running your latest chrome V.74.0.3729.108, but I also had the same issue with the previous version. Please find attached a file containing the output, but please don't busy yourself a lot with this issue. It's not really that important.

You know, I have fallen in love with Puppy, and I think I probably have most of the popular Pups installed on USB sticks, TahrPup, Slacko, Xenialpup, Bionicpup, LxPup, Dpup Stretch-7.5 and Fatdog64. I have a bit of a convenience reason for using Tahrpup64. It's the highest Pup version which could fit on a 250MB SD card I pulled from a dead old camera. My favorite laptop HP EliteBook can boot from SD card, so this works great as having two drives, and I don't need to dual boot with Windows, or should I say Windoze as I have seen you call it in some posts
.

[amn87]

Will it work in Bionicpup64 without having to mess around with missing dependencies etc? If yes which is better the .pet or .sfs from a RAM consumption POV?

[Mike Walsh]

@ amn87:-

Will it work in Bionicpup64 without having to mess around with missing dependencies etc? If yes which is better the .pet or .sfs from a RAM consumption POV?

It should fire straight up. It's self-contained, as far as dependencies are concerned. And Bionicpup64 was the Puppy that prompted the relocation from /root/spot to /home/spot, bringing it more into line with Big Brother's "requirements".

The browser will use exactly the same amount of RAM in the un-packed, i.e., running condition. The .pet package or SFS are simply different ways of installation, though the SFS is recommended; these are big browsers, occupying something like 340 MB of RAM simply 'ticking-over'. By using the SFS, you can unload it when not required, thereby freeing-up RAM for other uses.

The .pet package will permanently occupy space in your save-file/folder. I built those for certain of Barry's experimental OSs, where they cannot apparently make use of SFSs, since they're installed in 'full' mode. For everybody else, the SFS is the method I recommend.


Mike.

[RickGT351]

I have got Debian Dog on a flashdrive but it's as slow as a wet week

/offtopic

If you are looking for another good platform for Chrome, take a look at Debian Dog 64. Main advantage is that you can install it straight off the Chrome website and it automatically adds the repository so that you can keep it updated via apt-get like any other application. You can then run it as root with a simple script.

I did an explanation of how to do it, I'll add the link as soon as I find it.

edit:here it is

http://www.murga-linux.com/puppy/viewto ... 150d32909c

[Mike Walsh]

Afternoon, everybody.

The current stable version of Chrome - Google_Chrome-75.0.3770.80-amd64 - is now available for download, from the location referenced in post #1.

------------------------------------------------

Changes and updates in this release are as explained here, on the regular Chrome blog page.

42 security issues have been addressed since the previous release.....2 of which were considered 'High Severity'.

----------------------------------------------------

The glib-compile-schemas compile command now auto-runs at boot time. Downloads/uploads, therefore, work as they should.

The 'Spot2Root' file permissions changer has also been updated, and has been re-written to remove the need for the intermediate 'Spot2Root' directory in /usr/share.

------------------------------------------------------------------

Credits (as usual) :-

Battleshooter - for help with the self-contained NSS libs'n'stuff several releases back.
belham2 - for cobbling together the 'launch' script that is now employed.
And further back, 01Micko (the 'head honcho'), and iguleder - both of whom have indirectly helped keep this thread going for as long as it has, with references & links.

Thanks must also go to OscarTalks and peebee, for suggestions and assistance over the last couple of years.

---------------------------------

Any problems, you know how to get in touch.....preferably on the thread, so 'issues'/'fixes' are made available to all.

Enjoy.


Mike.

[cmonnnnnnn]

It seems to run fine in my xeniapup live CD sessions But when I decided to try bionic Pup I find that Google chrome will not run. Experimenting with puppy is a great way to learn about Linux. I'm not fluent, but I understand a lot of the technical issues . Debian does not allow apps to run under root. I thought xenia pup was Debian-based . In addition to being able to use chrome I like to learn, so why does it work in one distro and not the other?

Elsewhere in the forum is a link to another amazing user who posted installation files for chrome, but they are old, and don't run on my system. When I have tried to install Google chrome, it has only installed. The name "Google chrome" into my Internet menu, and I don't know how to eliminate remnants of that failed attempt. So any other time I tried to install, . I get the failure message that Google chrome is already installed .



I think it's easy to make a strong case for chrome as an important browser in the ugly world of the Internet . A lot of streaming services demand chrome, , in particular, YouTubetv , which is one of the reasons I disconnected my cable TV, but they won't support chrome . Sometimes I can slip Firefox pass them and see some of the hundreds of movies. I have on DVR , but Firefox ? Gimme a break
.

Chromium is NOT chrome... no native HTML5, and no access to android apps on the play store . Not everybody has a smart phone, but a lot of people need to use such apps that so many businesses. Send us to . Hell, I use it to refill my medications at the pharmacy . Chrome matters, Even though I'm anything but a Google fan .


I'm curious to know if anyone on behalf of the puppy development team can say with conviction, yes or no? Will I ever be able to use chrome, if I decide to use bionic pup Or should I just move on to something else .
I'm saddened, at some of the posts I have read. Not just here, but across all of the sites that turn up. When I search for "chrome and bionic pup" a lot of the responses seem to be based on a personal dislike for Google's chrome, and a dismissive wave of the hand, I seriously want to note here that I'm being sarcastic To say that . this Makes me feel like a conservative on Facebook. LOL just a joke folks, but actually a pretty good description of what this feels like
.
I don't know enough about Linux to build my own files, and I'm no longer motivated to continue to learn, but I will credit puppy for inspiring me to learn a lot about Linux that I never thought I would know
.
Please help ? If the only alternative is Firefox, I'm not sure there are any useful alternatives.

Thanks much and hope I don't offend or sound like a newbie complainer. I've seen a lot of those in this form since the early 80s, and I never want to be like that

John

[Mike Walsh]

Hallo, cmonnnnnnn. And to 'the kennels'.....

Well, now. First thing I need to know; are you running 64-bit Bionic, or 32-bit Bionic? I've just booted a pristine copy of Bionicpup64-8.0, and loaded the SFS package of Chrome 75 into it. I'm posting from it now.

You are aware that Chrome has been 64-bit only for quite a while, yes?

If you're running the 32-bit version of Bionicpup, Chrome cannot run, because it's the wrong architecture. I do, however, have an available package of Iron 69, from SRWare, that will run in 32-bit Bionic, and do everything that Chrome can, because it uses the Chrome 'binary' (it's not really a 'binary', but I call it that for convenience).

If you specifically want Chrome, then make sure you're running the 64-bit version of Bionicpup, and you shouldn't have any problems. The SFS package is the recommended one to use, because you can load/unload it 'on the fly', while Puppy's running; this way, it only occupies space in RAM while it's operational.

You can find a link to the current Puppy Chrome packages back on page #1, post #1 of this thread. These packages have had to be built in such a way that they will work with Puppy's '/root/spot' model; if you've attempted to use the .deb package, direct from Google's download page, not only will it not run, but it also messes up printer permissions in Puppy, too.

---------------------------------

With regard to the recalcitrant Menu entry, it's quite easy to get rid of. First, go into Menu->Setup->Puppy Package Manager. Click on the 'Uninstall' button. Scroll through the list of installed packages till you find the Chrome entry, and uninstall it. Wait till the PPM has done its thing, then close it. Have a look and see if the Menu entry for Chrome has gone.

If not, then follow these steps:-

Open ROX (the 'Files' icon on the desktop). Click the arrow, far left of the Menu bar; this takes you up a layer, into the file-system proper. Navigate through to/usr/share/applications. Look for the Chrome .desktop entry. Delete it.

Then, open a terminal, and type the word

Code: Select all

fixmenus

Hit 'Enter'. Wait till it's finished, then close the terminal. Now, re-start 'X'.

The Chrome menu entry should now be gone. I believe you can also accomplish the same thing by the use of the 'Re-build Menu' entry in the log-out GUI, but I've always just done this the way I've been used to, via the terminal. The end result is the same.

Hope that helps.

---------------------------

Personally, I agree with your views on Chrome. I'm a long-term user, having started with the initial public 'beta' release back in Autumn of 2008. I fell in love with it then, and have seen no reason to change my views. I used to be an ardent Firefox user, but at that time FF had serious issues with constantly crashing at the slightest excuse, and I went right off it. That is, until Quantum came along; it's turned out to be everything FF could have been years ago, were it not for the constant in-fighting and back-stabbing in the Mozilla camp.

TBH, I use both equally as much now.....along with Palemoon, which is a great, lightweight browser for Puppy on old, RAM-challenged hardware.

I also tend to agree with you about the Google ecosphere in general. I'm not keen on the way in which they seem to have their fingers in every 'pie' out there.....but I willingly admit, I DO make frequent use of certain of their services. The 'Save to Drive' extension in Chrome being a good example, since it ties my browser and my cloud storage together beautifully; the 'Drive' is where I keep all the Puppy packages I share with the community, so ease of access is paramount. And one of our Forum members has put together a 2-pane file manager which lets you organise your Drive stuff without needing to even open the browser; it simply makes use of a long-standing API Google have had available for years for just this purpose, accessing it via 'wget' in the terminal to set-up the initial connection.

Just so you're aware (:lol:), there's lots of Puppians who are convinced that Google is the devil incarnate. Makes for some lively, heated debates on occasion!


Mike.

[peebee]

Hi Mike

An oddity for you......

I tried Google_Chrome-75.0.3770.80-amd64 in ScPup64-19.06

The missing dependency on GTK3+ was easily fixed, however.......

when running via your wrapper I got:

# ./chrome.sh
/home/spot/google/chrome/chrome: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

Checking the Chrome binary libpng12 was not shown as a dependency and the actual dependency on libpng16 is satisfied:

# ldd /home/spot/google/chrome/chrome | grep png
libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f9c8428b000)

and indeed running the binary directly with:

# run-as-spot /home/spot/google/chrome/chrome

worked fine.

Looking at your wrapper chrome.sh I can't see where the dependency on libpng12 is coming from???

Any ideas?
Thanks
peebee

[Mike Walsh]

Morning, peebee.

Hm. That's an 'odd one', indeed. It's not happening for me, either in my own install of Xenialpup 64, or in 'clean' frugals of Xenial64 & Bionic64.

I can investigate, certainly, but I'm not quite sure where to look, in all honesty. I wonder if it's a peculiarity of your own Pups?

(Mind you, don't forget I'm not as good at this coding stuff/bash scripting as you are. That wrapper script is a slightly modified version of the one belham2 came up with a while back when all this 'run-as-spot' stuff initially cropped up, back around 62/63? It continues to work on my own machine, so I continue to use it....

Not very scientific, I know..!)

I don't use any Slackware-based Pups at all now, with the exception of Slacko 560, though I do recall they're rather more fussy with this png stuff. Not much else I can say at the moment, and I haven't had any real complaints as such from other Puppians for quite a while on the thread., so it's hard to say whether or not anybody else has noticed it...

Mike.