Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this page for instructions on how to get full permissions. Sorry for the inconvenience.
It would be nice to have an application available for copying files to/from the phone, controlled from a laptop. The application could use NFS mounting and networking to provide such capability.
Of course, there is always ssh/scp too, but it may not be the best solution for phones.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
I'll try to provide a breakdown of different methods to achieve that known to me.
NFSv3 - No security by default, needs a VPN layer to do that. Not sure about anything else.
NFSv4 - Security requires Kerberos, difficult to configure and totally overkill. Not sure about anything else.
SSHFS - Easy to set up, but can only do one request at a time. Will hang up any application reading from the mount when disconnected, may prevent sleep/hibernation when mounted.
ADB - Doesn't need a network, needs special software which is not as battle tested as other solutions. Should be handling disconnects gracefully. No more data. (is this using MTP?)
WebDAV - HTTP-based, can be authenticated. Needs network. Not sure about anything else. wdfs
I assume we're doing to integrate with gvfs, so I'll add a point of anecdata - I set up SSHFS to a NAS for my friend, and with occassional usage we once hit the problem that the mounts are not accessible from the command line. This is specific to gvfs, whereas regular FUSE mounts work for anything.
If this is to provide remote access to work with some specific files on the phone over the network, would providing support for USB-mass-storage (connecting phone to computer) still be another separate issue?.
This already covers connecting the phone to the computer, through a (USB) network. We ruled out USB mass storage, because it requires the storage filesystem to be unmounted from the phone while the mass storage device is active.
I meant the standard way how phones pop up as connected usb devices.
That actually seems to be MTP or PTP, not mass storage, you're right.
With the exception of ADB, I would consider all methods above as remote access methods, and nothing to be active by default. Even the local ones should only be active if enabled, and the device is unlocked.
I've updated the description to reflect better what we want to do: copy files between the phone and a desktop (laptop). This could end up being a general solution for PureOS. This does away with the "remote/local" separation, which is not important here and IMHO ill-defined.
That being said, security should take into account that the one plugging cables might not be the owner of the device.
The term isn't clear to me at the moment. You could define it in some objective terms (routability? topology? cable connection?), and explain how it's relevant, and then I'll be happy to use it.
Otherwise, we're going to shake out the 3 aspects I listed above anyway, since they are all relevant to security in different ways.
Oh, I see you are deleting comments here. Not nice.
I had replied with my short impression "Your comment seems twisted." Because instead of answering my question concerning your negative assessment of the "remote/local" distinction (instead of providing some explanation or correction), it:
Asked for something that I had just written in my comment before (to illustrate the difference).
Tried to imply a demand on me.
Referred to some "3 aspects" that can not be identified above.
Three things that, at least for readers, obviously don't make much sense, aren't on-topic nor helpful.
I do think it makes sense to lock down any remote network access (especially plain-text protocols as listed above) even more than cable access, which requires physical access anyway (i.e. disable remote access ports, better don't even have any server packages installed by default). Because network ports are much wider accessible once opened, i.e. the meaning of "remotely".
I deleted your comment, because there's nothing one can possibly reply to it. I prefer to let relevant discussion going - this is not the place to express how people feel without elaborating. Granted, I should have edited it. If you want to discuss this further, please write me at email. I'm glad we're back on track though.
To clarify, I listed the "3 aspects above" - routability, topology, cable connection - to try to break down what you wrote before about "routable network" and "cable hardware" into properties we can reason about and evaluate. Perhaps you meant OSI layers distinctions instead?
You have misread my invitation to join the process of defining requirements as a demand.
What qualifies as "network access" to you? I assume that you mean IP-based communication, because other definitions of network (OSI) also include USB communication. Does an SSH tunnel qualify as a network? Does point-to-point IP connection, router or unrouted? A VPN connection? My confusion comes from the fact that there are many shades of "network", which have implications along several different dimensions, and while I imagine you have an idea of what you mean, I'm still not on the same page.
EDIT: I think that SSH over a dedicated Ethernet interface (IP routed or not) is perfectly safe to use, so I'd like to be proven wrong with examples.
We should allow SSH access to the Linux shell in the phone and SSH based file transfer (SCP) through the Wifi (for example switching the phone to hotspot mode for an laptop to connect to the Wifi) or through USB tethering, i.e. direct TCP connection between a laptop and the phone by USB.
BTW: Resolving the dynamic IP address of the device could work based on the automatic "filesystem data syncing" solution (#79), i.e. the default or a self-hosted syncthing IP discovery server.