Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2305 closed Enhancement (wontfix)

rpc access control

Reported by: fejesjoco Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 1.73
Severity: Normal Keywords:
Cc:

Description

I think I have a great idea: RPC access control. Currently the RPC server supports a single user with god-mode access. The rpc-password, rpc-username, rpc-whitelist, rpc-whitelist-enabled would become an array and I could add any number of users. No need for an actual array, it could be just postfixed with a number like rpc-username-0 and stored in settings.json like any other setting. There would be a new entry for users, the access flags. There would be rights like read info, add new torrent, delete torrent, stop and start torrents, change basic configuration.

It doesn't seem too difficult to achieve. There's no need for configuration, editing by hand is sufficient, there's no way to configure RPC via the GUI right now anyway. It could be extended for torrent-level access, like the creator of a torrent has extra rights, but that's not important right now either, simple global access flags would be a great start. Minor changes here and there, mainly in handle_request(), but nothing serious.

I need it badly so I'd be willing to code it myself if you were willing to merge it. What do you think?

Change History (7)

comment:1 Changed 12 years ago by charles

It's nice that you're willing to code this up yourself -- I appreciate the offer -- but I honestly don't see the use case for this. Even if there is one, I don't see how many people would ever need this feature.

comment:2 Changed 12 years ago by charles

  • Priority changed from High to Normal

comment:3 Changed 12 years ago by fejesjoco

I see, but that doesn't sound like a no :). I don't expect either that many people would use this, but some definitely would. It's a great thing that Transmission has a daemon version, and it sounds so trivial to have this feature. What people do now is restrict access to the daemon as much as possible because of the lack of access control. For example, I'm using the daemon on a WL500G router. It's not only me who has access to the router and they keep asking me to download stuff and want to know the progress. It would be nice to give them read-only access, or even let them add new torrents themselves, but not delete any. Generally, Transmission daemon is used pretty much like a client, not a server, for example the only reason I run the daemon on my router instead of letting uTorrent run on my PC all night is because of the noise and power consumption. This daemon has a lot of potential, to become more like a server, to serve smaller communities for example. Those communities do exist, think of all the private torrent sites. If you don't see it that way, can you at least make a poll or something?

comment:4 Changed 12 years ago by charles

It's not only me who has access to the router and they keep asking me to download stuff and want to know the progress. It would be nice to give them read-only access, or even let them add new torrents themselves, but not delete any.

Why not run multiple copies of the daemon, each serving RPC and the web client on a different port from each other? Then the other people accessing the router can all add torrents, without being able to mess with each other's sandboxes.

comment:5 Changed 12 years ago by fejesjoco

The answer is simple: 32 megabytes of RAM total :) And sandboxing is still no good for read-only access to other instances. And shared resources, like open ports, peer exchange, speed control, etc. Come on, seriously, it's not that big of a change. No poll then? How about simplifying my original idea somewhat and see how that works out?

comment:6 Changed 12 years ago by charles

  • Resolution set to wontfix
  • Status changed from new to closed

Come on, seriously, it's not that big of a change. No poll then? How about simplifying my original idea somewhat and see how that works out?

I don't like your attitude. Needling me like that is not going to get you anywhere. I don't have to bend over for every only-requested-by-one-person feature in trac, and don't have to revise your idea pending your approval.

This feature would add new code, configuration options, and maintenance responsibilities that would at *best* benefit a *very* small handful of users. And that's assuming I was still willing to include it after its single proponent pushed and needled me.

Also, please don't bother registering sockpuppet accounts. Any further votes/comments in this ticket from users who don't already have a track record on trac.transmissionbt.com will be cheerfully ignored.

comment:7 Changed 12 years ago by fejesjoco

I would accept your attitude if it were the usual request type, but how many of them offer to do the work themselves? I understand what you meant, but I don't understand why you told ME that. I offer to volunteer and you insult me? That wasn't pushing, that was me saying that I planned the patch and it really is not that big of a change. We both know that sockpuppet accounts won't do any good, but you told me anyway, thanks for the assumption. Now THAT attitude will get YOU nowhere. I didn't deserve that but don't worry, I'll still do it myself. So much for the open-source community, huh.

Note: See TracTickets for help on using tickets.