It's a simple launcher for Google Chrome that tricks it into thinking you're not root, so it lets you run it even if you're root.

In order to use it, install the package and use "puppy-chrome" instead of "google-chrome" in order to run Chrome.

There are two reasons why I wrote it:
1) Freedom! It's MY computer and I'll do whatever I want, no matter if Google doesn't want me to.
3) If we want to build PET packages out of Google's official binary package (which has the updater), we can do this without having to patch the Chrome binary or edit any files (using conventional tools like sed).

How it Works

It's simple, very simple. I executed Google Chrome with strace (a tool which lists calls to system calls) to find out which system calls it uses to find out who's the user who executed it.

This library needs to get loaded into Google Chrome, so it overrides the legitimate geteuid and therefore tricks Google Chrome. That's where LD_PRELOAD aids us.

The LD_PRELOAD environmental variable contains a list of libraries that are loaded into any process executed; in this case, we force Google Chrome to run with our evil library loaded it to it, which overrides the C library's geteuid().

And if you wondered, that's what puppy-chrome does, of course:

Code:

LD_PRELOAD="/usr/lib/libpuppygc.so" google-chrome

A very simple approach can be used against any application that hates root - I was able to get rid of the warning message in the vanilla ROX-Filer this way, too. I just had to override getgid instead of geteuid.

Who would have imagined that Puppy Linux would ever have needed something like a reverse sudo command. However, it only takes one major player with a popular app such as Google Chrome to warrant such a thing.

Your idea of an executable to call an executable using this library is interesting, even though not many Linux executables work like this - well, not yet anyway. A good thing to have available in Puppy - just in case it's ever needed.

So, presumably this executable would be supplied with a command-line argument i.e. the name of the program to be run. This argument would then get passed to your program, let it do its stuff in /tmp and then disappear. Good.

Best regards

Tronkel_________________Life is too short to spend it in front of a computer

Not sure how to implement this, but you could have something like the 'set icon' dialogue. where you start your 'antirootcheck' program, then drag and drop the offending and demanding binary onto it. And it creates a .desktop file and script for /usr/bin/ to start the obnoxious program!

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum