The one of the most valuable things in the World Wide Web beside the public available knowledge are files. Files which you can grab; and it does not matter they are Free or not. Files could be downloaded using various ways: when you grab them for yourself only or when not just grab but also provide others with the abilities to get them easily too. Due to the second point I like to use torrents. The one of my favorite BitTorrent clients is Transmission -- great OpenSource crossplatform software.
The one of the valuable features of Transmission is an ability to run as daemon not being depending on any kind of GUI toolkits. That's why it is common to use Transmission daemon on servers and various NASes. The daemon can be conveniently managed using any GUI client as well as a Web-interface or even command-line tool. The access to the daemon is controlled through credentials -- the pair of username and password which are stored in settings.json configuration file.
It is definitely cool to be able to protect my running Transmission daemon from my neighbour who works for RIAA :). But I do not like the idea that to manage the daemon safely I should to generate and keep in mind another access password. I asked myself why just not to use the credentials I already have? I mean credentials I already use to log to my Linux system in.
In Linux user's authentication to a system usually is performed using PAM infrastructure -- Pluggable Access Module. The infrastructure provides a single mechanism for managing and embedding of software applications to the authentication workflow.
So I decided to integrate PAM authentication for Transmission torrent daemon. And it was done for 1 day. The patch is available on my git repository. It is applicable for trunk@13057.
Enable PAM authentication for Transmission
The one of the valuable features of Transmission is an ability to run as daemon not being depending on any kind of GUI toolkits. That's why it is common to use Transmission daemon on servers and various NASes. The daemon can be conveniently managed using any GUI client as well as a Web-interface or even command-line tool. The access to the daemon is controlled through credentials -- the pair of username and password which are stored in settings.json configuration file.
It is definitely cool to be able to protect my running Transmission daemon from my neighbour who works for RIAA :). But I do not like the idea that to manage the daemon safely I should to generate and keep in mind another access password. I asked myself why just not to use the credentials I already have? I mean credentials I already use to log to my Linux system in.
In Linux user's authentication to a system usually is performed using PAM infrastructure -- Pluggable Access Module. The infrastructure provides a single mechanism for managing and embedding of software applications to the authentication workflow.
So I decided to integrate PAM authentication for Transmission torrent daemon. And it was done for 1 day. The patch is available on my git repository. It is applicable for trunk@13057.
Enable PAM authentication for Transmission
- Add a user which privileges the daemon is run on to the group which is able to read /etc/shadow file (if authentication in your system is performed in standard Linux way). Usually such group is called 'shadow'.
- Add to your Transmission's settings.json "rpc-native-authentication-enabled" parameter set to "true".
- Restart the daemon and try to re-connect using your system credentials.
The name of parameter is chosen in that way because of cross-platform intentions. For each system native authentication might differ from PAM. But most UNIX`es it will most probably be PAM.
Currently the feature is enabled for Linux only. I suppose it can work w/o any extrac magic on MacOS as well as on BSD.
Cons
- ssh-ready credentials are passed over network in the non-encrypted way;
For all my cases the credentials cannot (again: for my cases only) be sniffed. For other possible cases just use ssh-powerless credentials. And finally start using ssh key-based authentication!
- the daemon is able to read /etc/shadow file. If the daemon is taken over, a brute force attack to the password can performed.
If your PAM is configured in the way no to use pam_unix.so, there should be no problems. In other ways there could be some unless you are using one-time passwords.
Pros
- easy to maintain access to control Transmission daemon itself as well as allow 3rd-party trusted people to manage processed torrents;
No need to keep in mind another password. No extra reasons to change the password in cases when you shared daemon access for one time; just block guest account.
- PAM is just a frontentd but there could be any backend;
In the other words you are not forced to used system credentials to manage Transmission daemon. For example your PAM could be configured to perform user's authentication over LDAP or one-time SMS.
Using
The patch to add PAM authentication to Transmission torrent client is distributed in terms of GNU GPL v3.0+ license.
Since to its specific needs currently it is not going to be the part of main Transmission's branch. So if you maintain your own Transmission's fork/build please feel free to share your opinions regarding the feature.
No comments:
Post a Comment