On Fri, Nov 13, 2009 at 03:05:08PM +0100, Thomas Gebhardt wrote:
> Dear Herbert,
> > IMHO the chdir happens _before_ the --bind mount should
> > be affective, maybe you mounted it already there or
> > you have a problem with the barrier flag (note that
> > the debian 2.6.26 branch is broken and requires manual
> > fixes to all the attribute flags when switching to or
> > from such a kernel), besides that, I'd suggest to get
> > a more recent util-vserver snapshot ...
> ok, I changed linux-image-2.6.31.5-vs2.3.0.36.23-beng and
> util-vserver-basic-debian_0.30.216-pre2849 (which were advertised
> on this list recently), but that didn't change anything.
> > things which might work:
> > - you can do the bind mount before the the guest is
> > started (either permanently or via one of the
> > guest start scripts) and exclude the path from the
> > namespace cleanup
> > - you could put the actual nfs mount in the guest's
> > fstab.remote, as long as mounting itself can happen
> I tried these alternatives with "various" success: sometimes
> it worked, then suddenly it ceased to work. By sniffing the
> network traffic I noticed that the ip source address of the
> nfs requests changed from the vserver ip to the host ip
> some minutes after the vserver was started. This seems to be
> the reason for my permission problems.
> I also tried to mount the nfs share within the
> vserver manually (with SYS_ADMIN, SECURE_MOUNT, BINARY_MOUNT
> [b|c]capabilities enabled):
> mount -t nfs nfsserver:/home /home
> but the source ip address of the resulting nfs traffic was
> the host(!) address, not the vserver address.
> It might be worth to mention that the ip address of the vserver
> is bound to a vlan device while the host ip runs on native eth0.
> I can't see that this fact is of any influence for the flaw, however
okay, I guess we need more details about your setup,
specifically the nfs part (server, client, versions)
and of course, somebody to help with testing ....
best,
Herbert
> Thanks, Thomas
Received on Sat Nov 14 15:43:24 2009