Can I Use the FTP Server Without Compromising My Root Password?

[held]

All I wanted to do was copy large files and not use SFTP because its slow.

Forgetting that FTP is ancient, I forgot to switch to passive mode, so my firewall was blocking the ftp-server's attempt to setup a connection. Pffft...

After switching to passive mode I could login anonymously, but ended up in /home/ftp with read access only.
Or login with root and compromise my root password with write access in /root. Not what I wanted either.

So I figured maybe use FTPS to at least use SSL authentication, but ProFTPd has been compiled without

How do people use this?

[Stinky]

SFTP works fine for me.

[PistolsAtDawn]

If your home network is reasonably secure then I don't see why you would worry about compromising your password.

/root is the home folder of the root user, so it's natural that you would have write access there if you login as root. (/home/[user] is the home directory of every other user on that system.)

SFTP is going to be limited in speed because (as I understand it) by default the buffer size used is very small and this causes a bottleneck. Using a patched version of SFTP can achieve better speeds, however both the endpoints need the patched version for this to work. You mostly see this in enterprise setups and not at home.

FTPS shouldn't be strictly necessary on your home network. Unless you think somebody is actively on your network sniffing traffic, I seriously wouldn't sweat this.

[Malor]

As Stinky says, sftp is the easiest way to handle things; this is a file transfer service that works a lot like ftp, but transfers over a Secure Shell connection, so you don't give away any passwords. If you get SSH running, then sftp should be automatically included, and should work okay.

Using non-root FTP is possible, but you have to create a user account with a separate password. If you're uploading to the internal card (eg, /media/fat/games), the FAT filesystem there has no concept of security or permissions. As long as you grant R/W access in the ftp daemon, you should be able to load stuff with no issues from any user account, and it will all run fine from the main Mister menu. However, if you ever upgrade to a better filesystem (like by attaching an external USB device), you could run into permissions problems that you'd have to fix from the command line, possibly by creating a new group and assigning permissions to that.

I can show how to create users if you need to, but I'd recommend using SFTP instead. It just solves everything all at once, and it will keep working in the future. There's a little bit of friction in getting your client set up, but once that's done, you can just keep using it no matter what you do with storage on your Mister.

edit: also note that Windows 10 and later have a text-mode sftp client built right into the OS.

[held]

Thank for the response guys,but I really don't want to use SFTP because it takes twice as long (in my setup).

From my limited understanding everything is bound to "root" in the MiSTer and this goes for the sdcard "/media/fat" too.Its not possible to chown files/folders because of ExFat:

Code: Select all

/media/fat# chown ftp:ftp my_folder
chown: changing ownership of 'my_folder': Operation not permitted
/media/fat# 

So I thought I would add ftp to the group root, but there is no "usermod" either

Since OpenSSL is already in the image, it would not be much to ask to enable FTPS support in ProFTPd ?
(I found a small hint though )

Code: Select all

/home/saar/MiSTer/_repo/buildroot-2021.02.4

Where do I need to put in a request?

[jamespo]

But as previously mentioned why do you care about the password being sent in clear text on your home network, is someone sniffing traffic there?

[held]

I travel with it, mostly friends, but not always.

[PistolsAtDawn]

Malor's suggestion of creating a user with access limited to /media/fat/ (or even just subfolders) is probably the best balance of security and convenience within the existing tools.

I wouldn't count on FTPS getting enabled when NFS isn't available either. As I understand it, only a single line is needed to be added to the kernel config to enable it, yet we still don't have native network file sharing in favor of Samba/CIFS.

[held]

That's because they did not build the Linux OS from the ground up.

Buildroot is used as a base and that's imo where a lot of problems come from. I think they don't know how because of <insert> reasons. From what I've seen this Linux build can be _50mb instead of the _400mb it is now.

But its a hassle, no doubt about it.

[Malor]

NFS kinda sucks anyway. You have to have the portmapper running on any host, and it's just a real PITA to deal with. Local users map directly to remote users, by number I think, and there are just many security gotchas and issues with that system. A local root user is automatically remote root, unless you set a bunch of stuff relating to squash_root or something like that, and then those settings can cause more permissions problems that are awkward to deal with.

Samba is a lot easier and, IMO, more robust. As a client, you connect as a user, so you know what permissions you have remotely, and then if those permissions are set correctly, you can just use them without having to think about anything. All local users map to the remote user you connected with, so you get the same remote access no matter what. You will often get slightly oddball permissions listings when you ls a directory from a client machine, but the actual access permissions work correctly.

It's also a lot easier as a host, too.

Exposing newbies to NFS is, IMO, a thoroughly bad idea. It's ancient software, and requires a lot of study to use safely. It's also a real PITA to use with Windows.

[PistolsAtDawn]

Well I won't argue against your points as I think you're largely correct. My preference is still for NFS to work because I get much better performance out of it since the rest of my network is Linux hosts. I've never had any trouble configuring it, and security concerns are quite low my home network.

It's just an option, and options are good. Not every MiSTer owner is just discovering Linux for the first time. I've been using Linux distros since the late 90s, so I appreciate a non-gimped set of standard Linux OS tools. Having that option doesn't force anyone to use it, newbies included.

[Malor]

You really shouldn't see much, if any difference between a Samba share and an NFS share in terms of performance, at least with SMB3. The kernel speaks it natively, and it should be extremely efficient. On regular PC class hardware, even quite old machines, if you're not getting very close to wire speed with Samba, something is amiss.

NFS might be a little faster on a really weak CPU, but I think the ARM on the Mister is probably fast enough. Either as a server or as a client, the Mister's bottleneck with Samba is likely to be the USB link to the SD card or to the external storage. (edit: well, in pure client mode to a NAS, it doesn't touch USB, so that wouldn't be a choke point.)

Functionally, on the Mister there's not going to be a difference between the two, because either protocol should either be limited by USB, or by the Ethernet wire, before the CPU gets overtaxed. 800MHz is still pretty quick.

[PistolsAtDawn]

You really shouldn't see much, if any difference between a Samba share and an NFS share in terms of performance, at least with SMB3. The kernel speaks it natively, and it should be extremely efficient. On regular PC class hardware, even quite old machines, if you're not getting very close to wire speed with Samba, something is amiss.

NFS might be a little faster on a really weak CPU, but I think the ARM on the Mister is probably fast enough. Either as a server or as a client, the Mister's bottleneck with Samba is likely to be the USB link to the SD card or to the external storage. (edit: well, in pure client mode to a NAS, it doesn't touch USB, so that wouldn't be a choke point.)

Functionally, on the Mister there's not going to be a difference between the two, because either protocol should either be limited by USB, or by the Ethernet wire, before the CPU gets overtaxed. 800MHz is still pretty quick.

I hear you, and I also know this is the general wisdom on the matter. Perhaps I do still have some gap in my knowledge that would explain this, but in my home usage over the last two decades transfers between linux to linux hosts via CIFS/Samba have performed worse than NFS. I have attempted to configure both differently to close that gap, but I have never gotten it all the way there.

I agree that CIFS is superior to NFS as a default for the use case we have here. I know that linux curmudgeons like myself are not the majority of users.