On Fri, Apr 20, 2007 at 10:57:02PM -0700, Russ Allbery wrote: > I know that the page for rssh already says that you're not particularly > interested in adding support for new programs to the package, so I fully > expect the answer to this to be no.
It never hurts to ask... :) But yeah, the answer is still no. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284756 is a request > for Subversion support, very similar to the existing CVS support except > through svnserve instead. svnserve is a bit better designed than CVS's > server mode and the support should be fairly simple. This is the most > compelling one for me since it's very close to the existing CVS support > and a lot of CVS sites are switching to Subversion. The CVS support is marked as deprecated, because it may be possible to convince cvs binaries to execute a variety of other programs through "triggers"... The only way around this is to use rssh with a chroot jail, and make sure no binaries you don't want people running are inside the jail. Yucky. The only reason I haven't ripped support out altogether is a lot of people are already using it, and objected to it being removed, despite the concerns. You should probably only use the CVS support if it's only going to serve as a CVS server (and absolutely only use it in conjunction with a jail). I won't support Subversion because I don't know it, have no incentive to learn it, and suspect it probably has similar pitfalls. > There's a patch included in that bug against 2.2.3, but I expect it > would require some updating for the current version. If you're > interested in this, I could probably find some time to update the > patch. 2.2.3 has a local root exploit. I seriously hope you're not using it... > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323384 is a request > for passwd support. The request was to disallow all command-line > options so the person can only change their own password. No patch > for this one. I have several objections to this. - I don't want to add it because I don't see the need. In most cases, users will have access to other resources that share the same credentials; it's better to change the password on a different system and sync to the rssh server. In cases where that's not feasible, it's a fairly trivial matter to set up a web form to change the password; I'm pretty sure there are already solutions out there to do just that. Use one of those instead. - If chroot jails are in use, it CAN'T work. The passwd command will be run inside the jail, where it can not change the user's password. The only way it could be made to work would be to keep a copy of the passwd and shadow files in the jail, and periodically copy the version in the jail to outside the jail. But that's a huge no-no. The whole point of the jail is to limit the damage that can be done in case of a compromise; the data inside is assumed to be compromised. Thus any data that lives inside the jail CAN NOT be trusted, and CAN NOT be copied outside the jail. A compromise would mean that a user could modify the root password, or crack all the passwords on the system, or possibly worse. That's bad news. Though it originally lacked the support in early released versions, I wrote rssh expressly to provide the chroot jail functionality. My intent is that basically no one should use rssh without using jails, though there are certainly valid use cases for doing so. I would never add a feature which can not work cleanly with jails. And sure, the above could be made to work more safely by only copying a subset of passwd/shadow entries, and individually rewriting the changed ones, but... - you still will be required to trust data that should not be trusted - I don't see value to writing code to do all that, so I wouldn't do the work - it would need to be implemented by individual sysadmins, or other people who volunteer their code. - The "right" way (in this case, the least wrong way) to sync the passwords would need to be documented by me, and implemented carefully by the sysadmins who want to do this nonsense. As for the latter, my answer is, look at the archives of this mailing list. People don't read documentation, and don't read list archives. People have asked the same 3 questions (mostly the same one question) over and over again, even though the answers are documented in great detail both in the software, and in the docs online, and already answered numerous times on this list. A lot of people's approach to security is, "oh I'll just install some program and then I'll be safe," which is totally bogus -- you need to understand how your system works in detail in order to keep it secure. I could never add a feature that requires that much complexity to set up properly, unless the benefits of doing so were enormous (like adding chroot jails). Changing the password just isn't such a case. That said, the code is completely free, and the Debian folks are free to add whatever patches they want, as they are wont to do... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
pgpJqiGCPCfS5.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ rssh-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rssh-discuss
