From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: Detecting the use of a mount in another namespace
Date: Sun, 18 Jan 2015 11:51:11 -0600 [thread overview]
Message-ID: <87d26cvuy8.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <1421339341.29655.13.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (Alexander Larsson's message of "Thu, 15 Jan 2015 17:29:01 +0100")
Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> On Thu, 2015-01-15 at 10:34 +0000, Daniel P. Berrange wrote:
>> On Thu, Jan 15, 2015 at 09:56:05AM +0100, Alexander Larsson wrote:
>> > This is a bit of a weird request, but I'm working on an app sandboxing
>> > system where each container gets /usr read-only bind mounted from a
>> > hardlinked tree. When i update the /usr tree I write the new tree to a
>> > different directory, which avoids affecting any currently running apps
>> > against the old one.
>> >
>> > However, after updating I'd like to clean out the old version if it is
>> > not in use. I had a plan for this:
>> > 1) Move the old usr to a "has been deleted" location
>> > 2) Try to remove a file inside the user (say ".ref") which the app when
>> > running has bind-mounted somewhere
>> > 3) if the remove returned EBUSY, then the usr is in use.
>> >
>> > However, with the recent changes to the semantics in this area this
>> > doesn't work. The remove always succeeds even if the file is mounted in
>> > some other namespace.
>> >
>> > I realize that this is better semantics in general, but that was a quite
>> > useful hack. Is there any other similar way i can detect that something
>> > is in use in "any other namespace".
>>
>> Presumably you want something more efficient than scaning /proc/$PID in
>> the host OS ? eg you read /proc/$PID/mounts for each process, then iterate
>> stating /proc/$PID/root/<mount> to lookup the st_dev+st_inode of the mount
>> location to see if the one you care about still exists in any process ?
>> Not really going to scale nicely with large numbers of $PIDs, so perhaps
>> you could short circuit by keeping track of your container pid leaders ?
>
> Yeah, that doesn't sound very efficient. Keeping track of the pids is a
> bit painful, since the containers are not launched or monitored from
> some central place. Maybe there just is no good way to do this anymore.
> Just wanted to ask here to make sure i didn't miss any possibility.
The way I would recommend is to give each of your containers a read-only
snapshot of /usr, and then delete that snapshot when done.
Aka:
cp -ldr /usr /usr-snapshot
# Some time later when you are done
rm -rf /usr-snapshot
There are more elegant ways (btrfs snapshots etc) but the above will
work on every filesystem that supports hardlinks.
For what you were wanting to do with mounts in the general case the
kernel has never had enough information to do what you want to do with
mounts. Think remote filesystems like nfs. Information from remote
filesystems about who if anyone has a mountpoint somewhere simply does
not propagate between kernels.
Eric
next prev parent reply other threads:[~2015-01-18 17:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-15 8:56 Detecting the use of a mount in another namespace Alexander Larsson
[not found] ` <1421312165.8788.7.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-01-15 10:34 ` Daniel P. Berrange
[not found] ` <20150115103417.GC8057-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-01-15 16:29 ` Alexander Larsson
[not found] ` <1421339341.29655.13.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-01-18 17:51 ` Eric W. Biederman [this message]
[not found] ` <87d26cvuy8.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2015-02-10 10:34 ` Alexander Larsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d26cvuy8.fsf@x220.int.ebiederm.org \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox