It would be preferable to do a mount --bind --make-private in one atomic action

2 messages, 2 authors, 2011-11-23 · open the first message on its own page

It would be preferable to do a mount --bind --make-private in one atomic action

From: Anders Blomdell <hidden>
Date: 2011-11-23 14:05:28

The rationale is the race problems I recently found with pam_namspace (see https://bugzilla.redhat.com/show_bug.cgi?id=755216). The following small script and it's output shows what pam_namespace essentially does does, and the problems that might occur; assume that /work is automounted, then the following really confuses things:

(
echo '# Empty work'
findmnt | cut -c1-30 | grep work
echo '# First primary mount on work'
ls -ld /work/Fedora-16/.
findmnt | cut -c1-30 | grep work
unshare --mount -- /bin/sh -c "(
    mount --bind /work /work ;
    mount --make-private /work ;
    mount --bind /tmp /work ;
    echo '# Detached mount of work' ;
    findmnt | cut -c1-30 | grep work ;
    sleep 5 ;
    echo '# Before detached unmount of private work' ;
    findmnt | cut -c1-30 | grep work;
    umount /work ;
    echo '# Before detached unmount of bound work' ;
    findmnt | cut -c1-30 | grep work;
    echo '# Weird detached automount behaviour' ;
    ls -ld /work/Fedora-15/. ;
    umount /work ;
    echo '# Detached unmount') &"
sleep 1
echo '# Second primary mount on work'
ls -ld /work/Fedora-15/.
findmnt | cut -c1-30 | grep work
echo '# First primary mount on work no longer accessible'
ls -ld /work/Fedora-16/.
sleep 10
echo '# And the final remaining cruft'
findmnt | cut -c1-30 | grep work
)

Which gives the following output (no wonder I had problems understanding what went wrong with my machines :-():

# Empty work
├─/work
# First primary mount on work
drwxr-xr-x 4 root root 4096 Nov 23 09:37 /work/Fedora-16/.
├─/work
│ └─/work/Fedora-16
# Detached mount of work
├─/work
│ ├─/work/Fedora-16
│ └─/work
│   └─/work
# Second primary mount on work
drwxr-xr-x 4 root root 4096 Nov 23 09:36 /work/Fedora-15/.
├─/work
│ ├─/work/Fedora-16
│ ├─/work
│ │ └─/work/Fedora-15
│ └─/work/Fedora-15
# First primary mount on work no longer accessible
ls: cannot access /work/Fedora-16/.: Too many levels of symbolic links
# Before detached unmount of private work
├─/work
│ ├─/work/Fedora-16
│ ├─/work
│ │ └─/work
│ └─/work/Fedora-15
# Before detached unmount of bound work
├─/work
│ ├─/work/Fedora-16
│ ├─/work
│ └─/work/Fedora-15
# Weird detached automount behaviour
ls: cannot access /work/Fedora-15/.: Too many levels of symbolic links
# Detached unmount
# And the final remaining cruft
├─/work
│ ├─/work/Fedora-16
│ ├─/work
│ │ └─/work/Fedora-15
│ └─/work/Fedora-15

-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: It would be preferable to do a mount --bind --make-private in one atomic action

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: 2011-11-23 21:48:22

Anders Blomdell wrote:
The rationale is the race problems I recently found with pam_namspace 
(see https://bugzilla.redhat.com/show_bug.cgi?id=755216). The following 
small script and it's output shows what pam_namespace essentially does 
does, and the problems that might occur; assume that /work is 
automounted, then the following really confuses things:
I don't have opinions on this. But please CC: me when your proposal is
accepted, for TOMOYO checks mount flags but currently assumes --bind and
--make-private are not passed at the same time. I'll add (e.g.)
--bind/make-private to TOMOYO's mount flags.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help