At the moment, if you start an rsyncd that's not running as root using default settings it will have some trouble. rsyncd tries to use chroot by default, but this will always fail if it's not started by root. It does emit an error message in this case, but I wonder if some people find this a bit confusing until they discover the setting. I have in the past. It might be better that if attempting the chroot gives permission denied (because the server is not running as root), then it should go ahead and use the fake-chroot function. Assuming no security holes in rsync, the behaviour should be the same. This is consistent with the handling of the 'uid' and 'gid' parameters, which are ignored if the server is not started by root. The problem is that then people might think they have the protection of chroot, but actually not do so. At the moment I think the course that is most friendly to new and existing users is: * 'Use chroot' is slightly redefined to mean 'insist upon chroot' * The default option is 'use chroot = no', rather than yes. * Regardless of the setting, rsync always tries to chroot to the module base directory. * If chroot fails: - If 'use chroot' is no, then rsyncd uses the fake chroot system - Otherwise it fails as it currently does In this case: * People running rsync as root get the same protection they currently do. * People who install rsync as non-root get a more friendly installation and no less security. * People who want not to use chroot even when running as root will lose. The only real reason I can think of to do that is that chroot might be broken on your machine, e.g. because name resolution doesn't work after chrooting. If we want to allow people the choice even when running as root we could change 'use chroot' from just being binary to being 'yes', 'no', 'if-possible', or something similar. Another alternative is to * Leave the default as 'yes' * If not running as root, and 'use chroot' is true, then just give a warning rather than aborting. Any comments? -- Martin
Hi Martin, In message <20010831173927.F27383@valinux.com>, Martin Pool writes:> * People who want not to use chroot even when running as root will > lose. The only real reason I can think of to do that is that > chroot might be broken on your machine, e.g. because name > resolution doesn't work after chrooting.What about resolution of symbolic links? If you chroot to a directory that contains a link pointing outside the directory tree, and want rsync to follow links, it won't work. This is a major shortfall, IMHO. -- Alberto **************************************************************************** Alberto Accomazzi mailto:aaccomazzi@cfa.harvard.edu NASA Astrophysics Data System http://adsabs.harvard.edu Harvard-Smithsonian Center for Astrophysics http://cfawww.harvard.edu 60 Garden Street, MS 83, Cambridge, MA 02138 USA ****************************************************************************
I think that all we should do is provide a more useful error message when not running as root and the "use chroot = no" option has not been specified, a message that suggests using "use chroot = no". I implemented "use chroot = no" because I wanted to run rsync --daemon as a non-privileged user, and I'm not entirely confident about the checks I put in place to prevent somebody from accessing any files outside the root directory. I think they're right, but as far as I know nobody but me has ever tried very hard to break it. I'd rather have people who aren't running rsync as root be forced to realize that they aren't getting as good protection. - Dave Dykstra On Fri, Aug 31, 2001 at 05:39:29PM +1000, Martin Pool wrote:> At the moment, if you start an rsyncd that's not running as root using > default settings it will have some trouble. rsyncd tries to use > chroot by default, but this will always fail if it's not started by > root. It does emit an error message in this case, but I wonder if > some people find this a bit confusing until they discover the setting. > I have in the past. > > It might be better that if attempting the chroot gives permission > denied (because the server is not running as root), then it should go > ahead and use the fake-chroot function. Assuming no security holes in > rsync, the behaviour should be the same. This is consistent with the > handling of the 'uid' and 'gid' parameters, which are ignored if the > server is not started by root. > > The problem is that then people might think they have the protection > of chroot, but actually not do so. > > At the moment I think the course that is most friendly to new and > existing users is: > > * 'Use chroot' is slightly redefined to mean 'insist upon chroot' > > * The default option is 'use chroot = no', rather than yes. > > * Regardless of the setting, rsync always tries to chroot to the > module base directory. > > * If chroot fails: > > - If 'use chroot' is no, then rsyncd uses the fake chroot system > > - Otherwise it fails as it currently does > > In this case: > > * People running rsync as root get the same protection they currently > do. > > * People who install rsync as non-root get a more friendly > installation and no less security. > > * People who want not to use chroot even when running as root will > lose. The only real reason I can think of to do that is that > chroot might be broken on your machine, e.g. because name > resolution doesn't work after chrooting. > > If we want to allow people the choice even when running as root we > could change 'use chroot' from just being binary to being 'yes', 'no', > 'if-possible', or something similar. > > Another alternative is to > > * Leave the default as 'yes' > > * If not running as root, and 'use chroot' is true, then just give a > warning rather than aborting. > > Any comments? > > -- > Martin
The OpenVMS C runtime support currently does not have a chroot(). So I have to go to "The Single UNIX (R) specification, Version 2 from The Open Group" web pages to find out what it does. It lists the function as LEGACY implying that it should not be used in new code. It also states that "There is no portable use that an application can make of this interface." The concept of a single root directory does not exist on OpenVMS. As such, the chroot() function does not mean anything more than chdir(). My guess is that on UNIX, it's main purpose is to prevent ".." from traversing below a certain point in the directory tree. Primarily to prevent an application running as root or setuid from using a relative path to gain unintended access to files. The concept of a single root directory does not exist on OpenVMS. As such I have been aliasing chroot() to just be chdir() just to get rid of the "no chroot" diagnostics. In the OpenVMS environment, it appears that there should be little reason to run the rsyncd as the "root" equivalent account. I will probably have to look at this issue further to determine what the root type privileges are used for. -John wb8tyw@qsl.network Personal Opinion Only