On Tue, 30 Nov 2010 13:31:07 +0100
Herbert Poetzl <herbert@13thfloor.at> wrote:
> On Tue, Nov 30, 2010 at 01:40:11AM -0600, Corey Wright wrote:
> > feel free to ignore my below input, as i have no intentions of using
> > your debian packages (i backport the official debian package instead),
> > but just to provide an alternate perspective.
>
> > On Mon, 29 Nov 2010 11:45:02 +0100
> > Ghislain <gadnet@aqueos.com> wrote:
>
> > > > This is a problem with the package util-vserver-basic-debian. If it
> > > > isn't installed on an already existing vserver kernel, it won't
> > > > work. I think Ghislain who builds those packages might be
> > > > interested in sorting that out.
>
> > > > The workaround is to reboot with the new kernel (which installed
> > > > fine for you), then to run
>
> > > > apt-get -f install
>
> > > > to get the utils installed.
>
> > > > Cheers,
> > > > ==
> > > > From Ben Green
>
> > > yes perhaps i should simply refuse to install on non vserver enabled
> > > kernel. Do you see any useful scenario where the util should install
> > > on a non vserver enabled kernel ?
>
> > yes: i install debian and later install a vserver-enabled kernel and the
> > utils... but you want me to first install the vserver-enabled kernel,
> > reboot, and then install the utils?
>
> > > with kernel that are not enable barrier setting fails
>
> > so don't set the barrier on non-vserver-enabled kernels.
>
> > /etc/init.d/util-vserver:98 "if [ -e /proc/self/vinfo ]"
>
> > > and therefor the
> > > user is responsible to create it later
>
> > why not automate it for the user on every restart (in case the user
> > creates a new guest or moves one since he installed your package and
> > you set the barriers)?
>
> what if the user doesn't want to have the barrier set for
> a certain directory containing a guest?
then feel free to modify the init script so that it doesn't set the barrier
for particular directories (add an environment variable
in /etc/default/util-vserver to contain directories you don't want the
barrier set on and then test/grep that variable before setting the barrier
on each directory) and submit your patch as a wishlist bug on the debian
package. "patches welcomed" ;-)
> > /etc/init.d/util-vserver:127-138
> >
> > # Then set the chroot barrier
> > for vserver in `ls /etc/vservers`
> > do
> > vdiractual=`readlink -f /etc/vservers/$vserver/vdir`
> > if [ -d "$vdiractual" ]
> > then
> > setattr --barrier $vdiractual/..
> > fi
> > done
>
> > vrootactual=`readlink -f /etc/vservers/.defaults/vdirbase`
> > setattr --barrier $vrootactual $vrootactual/.pkg $vrootactual/.hash
>
> what's the idea behind that?
i'm not sure about the .pkg and .hash, but i
presume /etc/vservers/.defaults/vdirbase is set because that's the default
base directory and in case no guest used the default (and therefor
barriers had only been set on each guest-specific base), then a barrier
still gets set on the default.
> > > that seems to me a security issue
> > > as no one will do it . So i think i will simply prevent any install
> > > on non enabled kernels if no one has any other advice on this.
>
> > i don't disagree that the user will be unlikely to set the barrier(s)
> > himself, so why not do it for him and allow it for non-enabled kernels
> > too, but test for the kernel capability at run-time (otherwise either
> > you blindly assume that the user has a vserver-enabled kernel or you
> > require the user to exclusively use/install your vserver-enabled
> > kernels; both are suboptimal and avoidable).
>
> personally I'd prefer a check and warning over this
> automated behaviour anytime, I don't like runlevel
> scripts which think they are smarter than the admin
feel free to delete the runlevels. "update-rc.d -f util-vserver remove".
or if "update-rc.d" is too debian-specific for a new debian user, then use
the more direct "rm -f /etc/rc*.d/*util-vserver" (which an experienced
linux admin/user should be able to figure out, even on behalf of a new
linux user... until upstart/systemd displace sysvinit, grrr). and feel free
to add whatever you want to /etc/rc.local.
but i appreciate that debian covers the common/80% case in their init
script and gives me the "freedom" to customize for the other 20% of use
cases (eg the init scripts are easily modified shell scripts and are not
automatically replaced on package upgrades if modified). the other 20% are
usually advanced/unique use cases, so those users shouldn't be surprised
they have to modify an existing distro package config or create their own.
i feel this is also "secure by default" first to new linux-vserver users
and secondly to those that fall into the 80% use case, which was (partly)
ghislain's concern: "that seems to me a security issue as no one will do
it".
so i recommend automating the barrier setting (by default as it's probably
appropriate 80% or more of the time and can be modified/removed if not) and
you recommend only checking and issuing a warning (ie "setattr
--barrier /etc/vservers/<guest>/vdir/.."), which i see both as better than
the reported behavior of the current package (ie installation fails if not
running a vserver-enabled kernel as it tries to set one or more barriers).
> but OTOH, I do not care that much as I don't use
> debian or the packages in question ...
but i appreciate hearing others experience, insight, opinion, etc as it
adds to the collective knowledge/wisdom of the mailing-list/community, so
thank you for sharing.
> best,
> Herbert
>
> > corey
> > --
> > undefined@pobox.com
>
corey
-- undefined@pobox.comReceived on Tue Nov 30 16:23:39 2010