Re: [spambayes-dev] Running sb_server.py from init under Linux
Tony Meyer wrote: It's a fundamental principle of Linux security that processes run with the minimum privilege level necessary to do their job, hence my earlier question whether it needed to be root. Another Linux fundamental is that the user has control over what happens. I believe the user should decide 'who' runs sb_server, not the script itself (i.e. the developers). If running sb_server.py actually required running as root, then I agree that would be a problem. It does not, however. Well, obviously there's a disagreement there. Butt none of the standard Unix services run as root by default unless there is some reason they have to do so, and that's for a reason. Apache, for example, will run as root if you ask, but the default configuration doesn't run it as root, and surely no-one would ever want to run it that way. In any event, if one were going to address this generally, the right place to do so is perhaps in configuration. What do we do on Windows? [etc] But this means that sb_server starts behaving differently on different platforms. I'm -1 on anything that does that. What's wrong with having a separate script that does what you want (like the Windows ones), leaving sb_server properly cross-platform[1]? That doesn't seem non-cross-platform to me. It just seems like taking advantage of a facility that is available on *nix and not available on Windows. It's possible that the second-script option could be made to work, for the more limited idea. That script could perhaps simply lower its privileges and fork a new process that would then pass control to sb_server. I'll look into that. But I don't see how one would get finer-grained control that way: E.g., running the process that binds ports as root, but running the web interface and proxy as an unprivileged user. By the way, the purpose of the mutex code seems to be to keep sb_server from starting multiple instances (or is that not its purpose? I don't do Windows). Anyway, if that is it's purpose, then it may not need replication on Linux, anyway. At least when I start sb_server from an initscript, it won't start multiple instances. I'm not sure why not. Cheers, Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://bobjweil.com/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto ___ spambayes-dev mailing list spambayes-dev@python.org http://mail.python.org/mailman/listinfo/spambayes-dev
Re: [spambayes-dev] Running sb_server.py from init under Linux
[Richard Heck] the suggestion was that sb_server.py should handle these things itself (as most system daemons do), that is, lower its own privileges if it discovers that it is running as root I'm -1 on this, personally. IMO it's up to whoever runs sb_server.py (or any of the other SpamBayes scripts) to decide what user should run it. What if a user wants to run it as root? What do we do on Windows? and then daemonize itself by forking and dissociating itself from the originating process. It sounds like what you actually want is a sb_daemon.py script that lowers privileges and launches sb_server.py (something like the pop3proxy_tray.py and pop3proxy_service.py scripts for Windows). Not everyone wants sb_server to run as a daemon. =Tony.Meyer ___ spambayes-dev mailing list spambayes-dev@python.org http://mail.python.org/mailman/listinfo/spambayes-dev
Re: [spambayes-dev] Running sb_server.py from init under Linux
Tony Meyer wrote: [Richard Heck] the suggestion was that sb_server.py should handle these things itself (as most system daemons do), that is, lower its own privileges if it discovers that it is running as root I'm -1 on this, personally. IMO it's up to whoever runs sb_server.py (or any of the other SpamBayes scripts) to decide what user should run it. What if a user wants to run it as root? No one who knew what they were doing would want to run it as root. It's a fundamental principle of Linux security that processes run with the minimum privilege level necessary to do their job, hence my earlier question whether it needed to be root. If someone wants to violate that principle, well, that is very silly. But if one wanted to allow it, then a command-line option would do so. There is the issue about ports below 1024, but that may not be terribly hard to address, at least in an indirect kind of way. What do we do on Windows? The code can check the platform and skip forking. Indeed, try: import posix #Go for it except ImportError: pass ought to be enough, since where posix is present (even on Macs), the rest will work. and then daemonize itself by forking and dissociating itself from the originating process. It sounds like what you actually want is a sb_daemon.py script that lowers privileges and launches sb_server.py (something like the pop3proxy_tray.py and pop3proxy_service.py scripts for Windows). Not everyone wants sb_server to run as a daemon. Perhaps not, but that could also be addressed with a command-line option. And if it's being started as root, then one will presumably be running it as a daemon. That too can be checked with os.getuid(). When I get a little time (a free afternoon, say), I'll have a more serious look at this issue and let you know what happens. In the meantime, I'll send a more secure initscript in the next couple days. Richard ___ spambayes-dev mailing list spambayes-dev@python.org http://mail.python.org/mailman/listinfo/spambayes-dev
Re: [spambayes-dev] Running sb_server.py from init under Linux
No one who knew what they were doing would want to run it as root. It's not my business to assume that I know better than they. If they have the ability to run something as root, then they should be able to do so. People who don't know what they are doing shouldn't use root at all. It's a fundamental principle of Linux security that processes run with the minimum privilege level necessary to do their job, hence my earlier question whether it needed to be root. Another Linux fundamental is that the user has control over what happens. I believe the user should decide 'who' runs sb_server, not the script itself (i.e. the developers). If running sb_server.py actually required running as root, then I agree that would be a problem. It does not, however. What do we do on Windows? The code can check the platform and skip forking. Indeed, try: import posix #Go for it except ImportError: pass ought to be enough, since where posix is present (even on Macs), the rest will work. But this means that sb_server starts behaving differently on different platforms. I'm -1 on anything that does that. What's wrong with having a separate script that does what you want (like the Windows ones), leaving sb_server properly cross-platform[1]? [This is also not a good way to test, since posix is not meant to be imported directly. Checking hasattr(os, fork) would be much better.] Not everyone wants sb_server to run as a daemon. Perhaps not, but that could also be addressed with a command-line option. I don't see the advantage of adding a command-line option (or several) over simply having a separate script. If I run sb_server.py in a console (which is the main way I run it), I do not want it to run as a daemon, and I don't want to have to specify an additional command-line option just to help people who aren't using sb_server properly. And if it's being started as root, then one will presumably be running it as a daemon. That too can be checked with os.getuid(). Explicit is better than implicit. Magically changing what happens depending on what user is running the script is not explicit. In the meantime, I'll send a more secure initscript in the next couple days. Note that the best place to put it is on sourceforge (http://sf.net/ projects/spambayes) as things are easily lost on the mailing lists. =Tony.Meyer [1] There is the open_platform_mutex code in sb_server. However, while there is only a Windows version there at the moment, adding versions for other platforms, if they were wanted, would be simple. ___ spambayes-dev mailing list spambayes-dev@python.org http://mail.python.org/mailman/listinfo/spambayes-dev
