[Twisted-Python] shedding root
I've seen how the plugins created by mktap can shed root and after binding to a port, and run as an unprivileged user... I'd like to do this in my twisted code, but my app isn't structured as a twisted "plugin". How can I manipulate the reactor (or whatever I need to tweak) to drop root after binding to say, port 80? I tried using standard python os.setuid() etc. but it just locked up the reactor. I looked in the API for useful material, but I was unsuccessful. Thanks!
On Tue, Apr 05, 2005 at 08:43:16PM -0400, Matt Feifarek wrote:
I've seen how the plugins created by mktap can shed root and after binding to a port, and run as an unprivileged user...
I'd like to do this in my twisted code, but my app isn't structured as a twisted "plugin". How can I manipulate the reactor (or whatever I need to tweak) to drop root after binding to say, port 80?
You can use twistd without using plugins. See http://twistedmatrix.com/projects/core/documentation/howto/application.html. In fact, mktap and plugins are almost never useful any more.
I tried using standard python os.setuid() etc. but it just locked up the reactor.
I looked in the API for useful material, but I was unsuccessful.
The place to look would be in twisted.application, but it's probably best to use twistd -y, as described in the doc I linked. -Andrew.
Andrew Bennetts wrote:
You can use twistd without using plugins. See http://twistedmatrix.com/projects/core/documentation/howto/application.html. In fact, mktap and plugins are almost never useful any more. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Whoa. If true, that sure doesn't come out in the docs. The link that you reference here says:
"There are many ways in which your code will be called by various parts of the Twisted framework by the time you're done. The initial one we're going to focus on here is a plug-in for the mktap utility." So although it's almost never useful, let's focus on a plug-in for the mktap utility. That's cute. - Steve
On Apr 5, 2005, at 9:33 PM, Stephen Waterbury wrote:
Whoa. If true, that sure doesn't come out in the docs. The link that you reference here says:
"There are many ways in which your code will be called by various parts of the Twisted framework by the time you're done. The initial one we're going to focus on here is a plug-in for the mktap utility."
So although it's almost never useful, let's focus on a plug-in for the mktap utility. That's cute.
That intro sure is misleading! The rest of the document doesn't mention mktap or plug-ins at all and in fact does document the currently recommended best practices. Pretend that first paragraph didn't exist. James
On Wednesday 06 April 2005 10:23, James Y Knight wrote:
So although it's almost never useful, let's focus on a plug-in for the mktap utility. That's cute.
That intro sure is misleading! The rest of the document doesn't mention mktap or plug-ins at all and in fact does document the currently recommended best practices. Pretend that first paragraph didn't exist.
So, should there be a deprecation warning when running mktap too? I see it plenty with *.tml plugin stuff... why not in plain mktap without stuff like buildbot, pynfo, et al. Plus a pointer like "see http://twistedmatrix.com/whynottap.html" would be nice. thanks, -- -jeff
On Wed, 6 Apr 2005 22:34:02 +0800, Jeff Pitman <symbiont@berlios.de> wrote:
On Wednesday 06 April 2005 10:23, James Y Knight wrote:
So although it's almost never useful, let's focus on a plug-in for the mktap utility. That's cute.
That intro sure is misleading! The rest of the document doesn't mention mktap or plug-ins at all and in fact does document the currently recommended best practices. Pretend that first paragraph didn't exist.
So, should there be a deprecation warning when running mktap too? I see it plenty with *.tml plugin stuff... why not in plain mktap without stuff like buildbot, pynfo, et al. Plus a pointer like "see http://twistedmatrix.com/whynottap.html" would be nice.
thanks,
There's no reason to break existing deployments, or even encourage authors to switch away from their current tap plugins, if tap plugins are satisfying their requirements. Deprecating mktap would just create a lot of unnecessary work. A document explaining the capabilities and shortcomings of tap plugins and comparing these to the other options for deploying a Twisted application is a great idea. Jp
Jp Calderone wrote:
There's no reason to break existing deployments, or even encourage authors to switch away from their current tap plugins, if tap plugins are satisfying their requirements. Deprecating mktap would just create a lot of unnecessary work.
A document explaining the capabilities and shortcomings of tap plugins and comparing these to the other options for deploying a Twisted application is a great idea.
Jp
The same could be said of most of the components of Twisted. Should one use twisted.web, or nevow? Manhole telnet or Manhole PB? Etc. I realize there might be some debate on use recommendations, but certainly consensuses could be gathered. Some place to start would be a big graph of the Twisted project, with flags for each component indicating stability, documentation status, future deprecation, and a short sentence about pro's and con's. Most of this information exists for these components, but it's dispersed among mailing list archives, docstrings, and once in a while, actual documentation. Something like this would be quite valuable: - twisted.project - ModuleA (Unstable) - Undocumented - Use ModuleB for future projects - ModuleB (Stable) - Documented (etc...) -k
Ooh. The graph idea is excellent; just to get a sense of what's IN Twisted. And perhaps as a navigation device for the docs. I'm not a Twisted expert, but I have some skill with graphical software; I could help make something like this happen, given interest and technical guidance.
Matt Feifarek wrote:
Ooh. The graph idea is excellent; just to get a sense of what's IN Twisted. And perhaps as a navigation device for the docs.
I'm not a Twisted expert, but I have some skill with graphical software; I could help make something like this happen, given interest and technical guidance.
So, most of the docs are API docs, which are generated by EpyDoc, so that might be tricky. Personally I'd be happy with a simple html table somewhere.
participants (7)
-
Andrew Bennetts -
James Y Knight -
Jeff Pitman -
Jp Calderone -
Ken Kinder -
Matt Feifarek -
Stephen Waterbury