mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5584] spotify: Error fcopy: invalid ownership for file /usr/bin/spotify #3035
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3035
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Jan 13, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5584
Reading profile /etc/firejail/spotify.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-devel.inc Reading profile /etc/firejail/disable-exec.inc Reading profile /etc/firejail/disable-interpreters.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/whitelist-common.inc Reading profile /etc/firejail/whitelist-var-common.inc Warning: networking feature is disabled in Firejail configuration file Parent pid 21820, child pid 21821 Warning: skipping spotify for private /opt Private /opt installed in 0.13 ms Warning: skipping none for private /srv Private /srv installed in 0.09 ms Error fcopy: invalid ownership for file /usr/bin/spotify Error: failed to run /run/firejail/lib/fcopy, exiting... Error: proc 21820 cannot sync with peer: unexpected EOF Peer 21821 unexpectedly exited with status 1@kmk3 commented on GitHub (Jan 13, 2023):
Basic debugging information is missing; please follow the bug report template:
@kmk3 commented on GitHub (Jan 13, 2023):
Please see the following links for how to format code blocks in markdown:
@smitsohu commented on GitHub (Jan 14, 2023):
Problem is here:
Error fcopy: invalid ownership for file /usr/bin/spotifyWhat does
ls -l /usr/bin/spotifysay?@aberja commented on GitHub (Jan 29, 2023):
I also have the same issue. Below is my bug report:
Description
firejail spotify returns errors and does not start.
Steps to Reproduce
in a terminal run
firejail spotifyExpected behavior
spotify should open
Actual behavior
I receive the error messages noted below in the log section.
Behavior without a profile
Spotify starts without any error messages when running without a profile:
Additional context
Environment
Checklist
/usr/bin/vlc) "fixes" it).https://github.com/netblue30/firejail/issues/1139)browser-allow-drm yes/browser-disable-u2f noinfirejail.configto allow DRM/U2F in browsers.--profile=PROFILENAMEto set the right profile. (Only relevant for AppImages)Log
Output of
LC_ALL=C firejail spotifyOutput of
LC_ALL=C firejail --debug spotifyEdit by @kmk3: Formatting.
@kmk3 commented on GitHub (Jan 29, 2023):
@aberja on Jan 29:
What is the output of
ls -l /usr/share/spotify/spotify?Does the error still happen with firejail 0.9.72?
@aberja commented on GitHub (Jan 30, 2023):
@kmk3
Yes, still happening with 0.9.72
output of
LC_ALL=C firejail spotifywith 0.9.72@kmk3 commented on GitHub (Jan 30, 2023):
@aberja on Jan 29:
Usually files in that location are owned by
root:root, which is probably whatfcopy is complaining about.
How was spotify installed?
Does changing the permissions change the output?
Example:
@aberja commented on GitHub (Jan 30, 2023):
@kmk3
Spotify was installed pursuant to the instructions on Spotify.com, i.e.:
Inside the folder /usr/share/spotify the files are owned by the user, while the folders are root:
Yes, changing the file permissions to root by running
chown -R root:root /usr/share/spotifyresolves the issue. As a result,firejail spotifynow starts spotifyGoing forward, does this mean that for those that want to run spotify with firejail, they will need to change the permissions? Or is there a change in firejail that can be made that recognizes how spotify installs?
@kmk3 commented on GitHub (Jan 30, 2023):
@aberja on Jan 30:
Usually everything in /usr/share is owned by
root:root.fcopy aborts because it detects an unusual scenario, which could be an attempt
to fool it into copying the wrong files (which could potentially lead to
privilege escalation).
The unexpected permissions seem like a problem in either the package or in the
package manager.
What are the permissions if spotify is uninstalled and re-installed through apt
instead of aptitude?
Did you create the
g752vsaccount or is it related to spotify?Is it a normal or a system account? Normal accounts usually have UID >= 1000.
@aberja commented on GitHub (Jan 30, 2023):
@kmk3
I purged spotify, restarted the computer and then re-installed using apt. The user g742vs then owned all files and folders in
/usr/share/spotifyI have tried this on another Debian install and the results were the same. I checked a number of other programs in /usr/share/ and the files and folders were all owned by root. So this issue appears to be only related to Spotify.
g752vs was the linux user account I created when I installed Debian and is not related to spotify.
It is a normal account. I have also included below the groups that the user belongs to:
@kmk3 commented on GitHub (Jan 30, 2023):
@aberja on Jan 30:
Good work; so the issue really seems to be with the spotify package.
@reinerh Any idea what could be causing this?
I'm not aware of any repositories related to creating the .deb package,
especially considering that spotify is proprietary software.
So I would suggest reporting this issue to spotify and maybe also contacting
Debian to let them know of the problem.
Closing for now since firejail is working as intended.
Feel free to post any related updates in this issue.
@reinerh commented on GitHub (Jan 31, 2023):
The data in the package is owned by UID 1000. That's a problem of the package created by Spotify.
No need to contact Debian, they have nothing to do with it. It's just an unusual third-party package. :)
@kmk3 commented on GitHub (Feb 2, 2023):
@reinerh on Jan 31:
Nice, thanks for debugging it.
Well, even if it's not the fault of Debian, I think that raising the issue on a
Debian bug tracker/mailing list would help bring visibility to it, especially
considering that Spotify does not appear to have either for the main program
(only a forum).
And since this is a security/packaging issue in the .deb package of a popular
service, I think it's not too unlikely that enough people from Debian would be
annoyed enough by it (and that someone might already know how to fix it) to put
pressure on them to fix it quicker than otherwise.
@aberja commented on GitHub (Feb 3, 2023):
This matter has now been reported here: https://community.spotify.com/t5/Desktop-Linux/Incorrect-ownership-of-files-installed-by-deb-package/m-p/5499572