Firefox downloads fail (solved)

[d-pupp]

I'm not sure if this is the best spot for this...
However it should affect all newer pups
I'm using Vanilladpup and when I went to update it the download failed immediately
Turned out I couldn't download anything from anywhere

I have found the problem
Firefox runs as spot and can't access anything not owned by spot (This is a good thing)
So all downloads have to go into /home/spot/Downloads
I had recently downloaded a archive file xxx.tar.xz that I extracted using pextract.
pextract changed the ownership of the Downloads directory to root:root so spot could not longer access the folder causing all downloads to fail
The fix is to change the owner and group
chown spot:spot /home/spot/Downloads
and maybe refresh the download location

Can anyone recreate this issues?

[mow9902]

I'm using fossapup64 9.6 (not vanilladpup) - but browsers in Fossapup also run as 'spot' (if selected to run that way).

My easy solution is to:

• create a folder named named 'my-downloads' in any location you choose

• symlink that folder into 'spot'

• symlink the 'spot' link into root

..and then in the browser simply select the download location as /root/my-downloads

This works for me for FF, Iron, Chromium etc

[mikewalsh]

@d-pupp :-

Moral of the story? Having downloaded anything into /home/spot/Downloads, don't try and work on it while it's still IN that directory. Move it to a dedicated "work area" (I've done things this way for several years, and have half-a-dozen "work areas", so I can - if necessary! - work on more than one thing at once).

I have a wee script that sits inside /home. I click on this, and it will re-set /home/spot's ownership back to spot:spot.....along with doing the same for the /root/spot sym-link.

For moving stuff into and out of /spot, I developed the Spot2Root utility some years ago. It moves items in whichever direction you wish, along with simultaneously setting the appropriate permissions. It runs from an icon in the notification area, and has had several updates over the years. Currently @ v4.3, you can find it here; both 32- and 64-bit versions are available:-

https://drive.google.com/drive/folders/ ... sp=sharing

Mike.

[d-pupp]

@mow9902 @mikewalsh
Thanks for getting back to me.
It seems this is not a new problem.

I will look at both ideas and have downloaded Mike's pet

Now that I know what's happening it's easy to fix if I forget and use pextract in the Download folder again. But it was a head scratcher for awhile

Thanks again

[bigpup]

This is not a problem but a feature of running as spot.

The idea is, the web browser running as spot, can only download to the spot directory and if something it downloaded, tried to execute something, it could not, because it does not have spot permissions.

However, you as root user can still do anything, anyplace in the file system, and run any program. Including inside spot directory.

That is exactly what you did, using pextract running it as root user.

[dimkr]

This is not a problem but a feature of running as spot.

Exactly.

In addition to classic concepts of file ownership and permissions, Vanilla Dpup has a second layer of security for applications running as spot, Landlock-based sandboxing that also reduces the attack surface for privilege escalation attacks (things like CVE-2023-22809). Even if you change the ownership of /root or /usr/bin to spot:spot, spot still can't read or write from these directories, so a malicious application running as spot is less likely to succeed at breaking your system, leaking personal data from /root, gaining root privileges on your system or infecting your Puppy with persistent (and hard to detect) malware.

IMO this is important because Puppy is a "community" distro without any kind of professional security auditing. I've seen .pet and .sfs packages that place files under /home/spot or /root but the directory inside the package has wrong permissions (for example, 777) or ownership. Most users probably don't verify that spot can't write to files under /root each time they install a package.

Bookworm Pup64 <10.0.3 had wrong permissions for /root out of the box, and this sandboxing mitigated the impact of this human error (without it, applications running as spot can write to /root and gain root privileges by modifying .bashrc, .profile, etc'). I believe other Puppy releases have more issues of this sort, especially those developers build on their own computer and not in a non-persistent, fully automated build environment.

[d-pupp]

That is exactly what you did, using pextract running it as root user.

I understand what you are saying and am grateful to @dimkr for setting it up the way he did.
The Internet is becoming a dangerous place.
what I meant when I said a known problem was with pextract changing the permission on the Download folder. That I don't understand??
Why does pextract do that?

[dimkr]

If pextract preserves the ownership and permissions of files when it extracts stuff, that's the right thing to do. The problem is more likely to be messed up permissions or ownership in the archive you extracted, if this archive contains home/spot.

[d-pupp]

If pextract preserves the ownership and permissions of files when it extracts stuff, that's the right thing to do. The problem is more likely to be messed up permissions or ownership in the archive you extracted, if this archive contains home/spot.

That is the strange part. The archive had nothing to do will puppy. I was looking at updating grub. The archive was grub2-mbr.tar.xz
And I extracted it from inside the Download folder....so how does it change ownership for the parent folder?

[dimkr]

Maybe it's not the extraction of the archive but something else you did that changed ownership?

[d-pupp]

@dimkr I think I found the reason. It has to do with the way tar works.
It was originally meant as a tape backup. Now it is used mainly to move files around from system to system.

Part one. tar by default when run as root preserves ownership and permission. However this is a problem when moved to another system so they can be stripped out. When tar extracts such an archive it uses the umask to set permissions and the owner is the user doing the extraction.

Part two. tar by default doesn't use absolute paths for security reasons. It strips the leading "/" and makes the path relative.
So when tar extracts the archive it has to start at the working directory and work it's way down.

I just confirmed this with a simple test.
I created a sub folder inside /spot/Download and set the owner to spot. Moved the archive into the the sub folder and extracted it with pextract.
It changed the sub folder owner to root but left the /spot/Download folder unchanged.

Moral of the story is... Put archived in sub folders before extracting them.