[Vserver] Re: Bug#378673: problem when /var/run/service is readonly inside vserver

From: Ola Lundqvist <ola_at_opalsys.net>
Date: Tue 18 Jul 2006 - 23:28:22 BST
Message-ID: <20060718222822.GB4708@opalsys.net>

Hi

On Tue, Jul 18, 2006 at 03:43:15PM +0400, Alexander Gerasiov wrote:
> Ola Lundqvist wrote:
> > Hi
> >
> > First of all this is not a bug in util-vserver. It is at most
> > a bug in mysql-server, but in this case it is not that either.
> No, it isn't. Mysqld works fine, the problems I have is in scripts wich
> clean /var/run on vserver start.
Yes, but that is what you can expect from any files under /var.

See the Filesystem Hierarchy Standard (FHS), chapter 5::
http://www.pathname.com/fhs/pub/fhs-2.3.html

The very purpose of /var is to have it read-write so that /usr
can be read-only. And /var/run is for "Data relevant to running processes"
or "Run-time variable data". It is even stated that "Files under
this directory must be cleared (removed or truncated as appropriate)
at the beginning of the boot process. Programs may have a subdirectory
of /var/run; this is encouraged for programs that use more than one
run-time file."

So in terms of this util-vserver do exactly what is expected from
a virtual server.

> >
> > Summary of below:
> > * /var can not be read-only
> /var - yes, but why /var/run/mysqld should be rw?

Because it is under /var.

> > * you can not communicate across vservers (or to main host that is
> > context id 0), using unix sockets.
> See below

Interesting! I was not aware of that, see below.

> > * You can only communicate using plain files, but then you can
> > of course not use read-only access.
> Well I need ro fs, but socket there is rw for both side. Again, see below.

I was not aware of that.

> >
> > On Tue, Jul 18, 2006 at 02:05:00PM +0400, Alexander Gerasiov wrote:
> >
> >>Package: util-vserver
> >>Version: 0.30.210-10
> >>Severity: normal
> >>
> >>Hi there.
> >>I want to push main host's mysqld socket inside vserver.
> >>So I think that the simplest way is to mount /var/run/mysqld from host
> >>to /var/run/mysqld on vserver. But that forces /var/run/mysqld cleaning
> >>on vserver's start.
> >
> >
> > You can not do that. Even if you create that socket for the vserver they
> > can not communicate. That is the main idéa about vservers that they
> > can not communicate with each other, except for the ways normal servers
> > can, like network.
> >
> >
> >>Then I made mount --bind -o ro (I also tried to specify that in
> >>vserver's fstab with the same behaviour), but in such situations vserver
> >>start fails with:
> >>=======
> >>#vserver bigfoot start
> >>chroot-shunlink("var/run/mysqld/mysqld.pid"): Read-only file system
> >>chroot-shunlink("var/run/mysqld/mysqld.sock"): Read-only file system
> >
> >
> > This is not a bug. /var is always read-write. /usr is the directory
> > where you can have read-only things in.
> >
> >
> >>Failed to start vserver 'bigfoot'
> >>======
> >>
> >>So I see here two questions:
> >>1st May be read-only subdir in /var/run shouldn't be fatal?
> >
> > It is not fatal, not even a bug at all.
> >
> >
> >>2nd Am I wrong? May be there are better way to do the same thing (I'm
> >>speaking not about mysql, I know that it's possible to use network
> >>socket, but I want to use the same scheme for some other services, so
> >>I'm interested in mounting something inside vserver with bind option.).
> >
> >
> > You need to use network sockets. That is the only way. If you want the
> > servers to communicate the way you want, then you do not want vservers,
> > but rather simple chrooted environments.
> Yes, chroot is fine, but it isn't so secure %) And it doesn't allow many
> other vserver features.
>
>
> Ok, look here:
>
> I start vserver.
> in vserver's fstab I have
> ====
> # tail -n1 /etc/vservers/bigfoot/fstab
> /var/run/mysqld /var/run/mysqld none bind,rw 0 0
> ====

Ok, read and write.

> so /var/run/mysqld on host and /var/run/mysqld on vserver are the same
>
> then on host
> /etc/init.d/mysql start
>
> in /var/run/mysqld on vserver i see mysqld socket. And this socked works
> %) Just trust me or test it yourself. For example not with mysqld but
> with anything other.

Ok.

> Another example - I wrote
> ====
> # tail -n1 /etc/vservers/bigfoot/fstab
> /var/run/mysqld /usr/test none bind,ro 0 0
> ====
Ok, read-only.

> And
> mysql -S /usr/test/mysqld.sock
> works fine in vserver.
>
> So UNIX-socket placed in fs ARE WORKING besides vserver and host, and
> your words are wrong (or this is wrong behavior of vserver, unfortunetly
> I see no good doc for vserver). I've cc to
> vserver@list.linux-vserver.org to listen for upstream point of view.

I'm obviously wrong. As this is actually the same file-descriptor this
may be expected behaviour, but I hardly think that this is something that
was created intentionally. It may be a security bug that you have found but
it may also be a feature.

> As you can see the only problem I have is that command "vserver bigfoot
> start" fails if there is read-only fs mounted somewhere inside /var/run.

But that is what you can expect, as /var/run is supposed to contain
read-write data, at least according to the standard.

But upstream vserver people may of course have another view and then
I'll reopen this bug.

> PS Guys from vserver maillist, please CC to me when reply, I'm not
> subscribed.

Best regards,

// Ola

> --
> Regards, Alexander.
>

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/  ola@opalsys.net                   Annebergsslingan 37        \
|  opal@debian.org                   654 65 KARLSTAD            |
|  http://www.opal.dhs.org           Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---------------------------------------------------------------
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Tue Jul 18 23:35:42 2006
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Tue 18 Jul 2006 - 23:35:49 BST by hypermail 2.1.8