Linux Mint
warpinator 1.6.4 and symbolic names #91
Replies: 2 comments
-
|
On the top of my previous input, I would like to mention that I don't see why warpinator could not be anywhere on the disks of the computer, several users can use the computer so the actual behavior brings more problems than solutions. I understand the security concern but I think that the solution should be more open to symbolic links and also the fact that several users can use the same computer and may have to access the data. |
Beta Was this translation helpful? Give feedback.
-
|
Are you having this issue with the Flatpak version or one from your package manager (or self-built)? The non-Flatpak has no problem with your incoming folder being anywhere, but it will resolve that location to an absolute path. However, since this preference is per-user, this shouldn't be an issue. If you're using the Flatpak, things are more complicated... A Flatpak has to declare which real folders are accessible, either read-only or read-write. In previous versions of Warpinator, these were:
As of 1.6.4, you are not allowed to keep your home folder as read/write, though it will start that way to allow freedom to select another location under it before locking it down. So are a couple setup details the user has to take care of, unfortunately:
You can do this either by using the Flatseal application (which it itself a Flatpak) or by changing warpinator's default flatpak launch arguments. To address the main point here, your save folder can be pretty much anywhere except for a few forbidden locations - the user's home folder itself, and some important dotfiles within it (.config, .ssh, etc...). But you need to make sure that whichever location you choose is exposed to the application using Flatpak's permissions. So a typical process to set this up would be:
If you do these steps in a different order (Choose the new folder in Preferences before setting its permissions), you'll need to re-choose the folder in Preferences after restarting Warpinator. It is a general characteristic of Flatpaks that makes this necessary. All of this is detailed here, as well as some more general information regarding folder security: I've updated the "Invalid save folder" message to include that link, so it'll be more discoverable to users. The non-Flatpak version of Warpinator has none of these issues (except for the forbidden locations), and no additional work is required when changing the incoming folder location. I can't relax the Flatpak's version's permissions - they did not like that we exposed the entire home folder in previous versions, and they definitely wouldn't be ok with exposing the entire filesystem as read/write without good reason, and there isn't one in this case, other than an explicitly allowed incoming folder. As the user, you can do whatever you want regarding folder permissions, including exposing your entire filesystem, though I don't recommend it. Again, if you want to be able to deal with multiple users I would suggest you'd be better off using the non-Flatpak version, where each user can set their own incoming folder location. Some information on why we needed to add more restictions: |
Beta Was this translation helpful? Give feedback.
-
Bonjour,
First try with warpinator 1.6.4 was not successful, after digging a little bit, I figured out that new controls have been set on target directory, so if your $HOME is /media/user/home/user (user directory on a private partition), the transfer request is rejected . because warpinator expects the target directory to begin with /home/user (should it be $HOME/user ??) , so it's either a bug or an undocumented restriction which could be documented and I certainly understand that not many people have this kind of configuration.
If the receiving directory is set to the physical directory name, it works, it's just symbolic names which are not understood by warpinator.
Please tell me if , for you, it's a bug and I'll open a new bug.
Regards
Patrick
Beta Was this translation helpful? Give feedback.
All reactions