[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
I'm not sorry. The change to Mint packages was the best thing I did to my desktop in a long time. This has saved me from so much frustration already. A recipe that works: https://www.osso.nl/blog/chromium-browser-without- ubuntu-snap-linux-mint/ Respectfully, Walter -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Won't Fix Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
Sorry but this should be marked "Won't fix" as per the Snapcraft team response on #9. ** Changed in: chromium-browser (Ubuntu) Assignee: Nathan Teodosio (nteodosio) => (unassigned) ** Changed in: chromium-browser (Ubuntu) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Won't Fix Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
** Changed in: chromium-browser (Ubuntu) Status: Confirmed => Triaged ** Changed in: chromium-browser (Ubuntu) Importance: Undecided => Low ** Changed in: chromium-browser (Ubuntu) Assignee: (unassigned) => Nathan Teodosio (nteodosio) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Triaged Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
I have purged all of snap from my machines, so I cannot reproduce. But I'm 100% positive Firefox suffers from exactly the same issues. The snap team decided that apparmoring applications was the way forward, even though this causes inexplicable breakage for some people who are just trying to get work done. The "as a community, we force people to adapt to far worse workarounds than running chown on files for much more common usecases" quote from James-Carrol, on the snapcraft forum is telling. :shrug: -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Confirmed Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
I can also reproduce this issue in Firefox (stable channel, version 104.0.2-1), can you? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Confirmed Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
Thanks for the forward! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Confirmed Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
> Yes, I will argue with you there. Don't get me wrong, yours is a totally valid use case. I'm just saying it's perhaps not that common, and perhaps doesn't justify the use of the "read: all" attribute on the home interface, which would mean that the interface wouldn't be auto-connected, which would affect many more users. With the current situation, it's a trade-off, and as such it doesn't address all the use cases perfectly. Now, I'll inquire with the snap security team whether using that attribute and requesting auto-connection would be acceptable, and if it is we'll make the change so that you don't have to tamper with system- wide apparmor abstractions to get what you need. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Confirmed Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
Let's see what the snapd folks have to say about it: https://forum.snapcraft.io/t/auto-connecting-the-home-interface-with- read-all-for-a-browser-snap/31525 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Confirmed Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
There are precedents for this use case, apparently: https://forum.snapcraft.io/t/interface-auto-connect-request-for-the- universal-update-utility-snap-home-read-all/23125. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Confirmed Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
Okay. So to unbreak the confinement in the mean time, one can do this:
(1) Find an include that is not owned by snap (because an update will
likely break things again):
# sed -e '/#include/!d;s/.*#include //' \
/var/lib/snapd/apparmor/profiles/snap.chromium.chromium |
sort -u
..
I choose abstractions/X.
(2) Edit that file -- /etc/apparmor.d/abstractions/X -- and place this
at the end:
# Give back read permissions to ALL files, not just user-owned-files
# Added here (it's included by /var/lib/snapd/apparmor/profiles/*)
# because snap likely won't give me a proper local hook to fix
# broken rules (LP: #1987945)
@{HOME}/[^.]** r,
(3) systemctl restart snapd.apparmor.service
Now you have succesfully "compromised security" on your system: all
apparmor profiles that include will get read powers in
your homedir. But your most used tool -- the browser -- is usable again.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1987945
Title:
[snap] chromium does not read root-owned files in $HOME
Status in chromium-browser package in Ubuntu:
Confirmed
Bug description:
Today, I literally spent hours trying to figure out why I cound't
upload a large file.
Of course I thought the problem was the size of the file.
It wasn't. The problem was that Chromium in Snap for some reason is
confined so that it can SEE file-owned-by-root.zip, but NOT READ file-
owned-by-root.zip.
I tried to upload the big file onto a PsiTransfer webpage. And it
simply stalled. The apache2 backend reported 400-errors and I got no
useful info out of that.
Chromium itself reported this in the Networking tab:
PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED
Which is totally useless. In no way could I expect that the ultimate
cause was that the local file was not owned by me.
_If I can see the file, and I have read-permissions on it, I expect
that I can upload the file._
Another example:
$ ls -l ~/Junk/rode_muur*
-rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg
-rw-rw-r-- 1 root root 64773 aug 27 18:08
/home/walter/Junk/rode_muur_root.jpg
Trying to upload rode_muur_root.jpg to e.g.
https://www.filestack.com/fileschool/html/html-file-upload-tutorial-
example/ yields this error-page:
This site can’t be reached
The webpage at
https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php
might be temporarily down or it may have moved permanently to a new web
address.
ERR_ACCESS_DENIED
That does not tell me that there is a problem with the local file.
That looks like a remote problem, am I right?
What would be the fix?
- Either don't show the file, if you're not letting me access it;
- or let me access the file;
- or, if that isn't possible, give me a reasonable error message. Having to
look in journalctl [1] as root to find out why a client application is
misbehaving is just not acceptable.
[1] # journalctl -t audit -n1 -o cat
AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium"
name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
(I know that I'll be complaining to deaf ears. You have your reasons
for putting all the browsers in snap. But from a user's perspective,
this whole snap thing has been One Giant Disappointment. I'm actually
considering moving to alternative distros after more than 10 perfectly
satisfactory years on Ubuntu.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
"Arguably" Yes, I will argue with you there. - How about tcpdump writing as the tcpdump user+group in my homedir? I can read them, delete them, but not send them to someone using the browser? - Me getting files as root, because I need special powers (for vpn, network, usb, ...)? mv(1)/cp(1) will not chown by default. - Having read-only files in a homedir, administered by root? If the argument is that no one is ever root to do user-stuff on their desktop, then you'll likely lose the power-users. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Confirmed Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1987945] Re: [snap] chromium does not read root-owned files in $HOME
Arguably, the case for files not owned by the user in their home directory is not very widespread. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files in $HOME Status in chromium-browser package in Ubuntu: Confirmed Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
