You are not logged in.
Pages: 1
Hi,
It used to be that a mount was a mount for all of the system. But since some time I noticed the following: I wrote a bash-script that does some complex mounting for me. And a created a desktop-Icon that runs this script with sudo. For testing purpose the desktop-icon run's the script inside a terminal:
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Type=Application
Terminal=true
Exec=sudo "/path/to/script/tcopen.sh"
Name=tcopen.sh
The script does stuff and then mounts with:
mount -o defaults,nodev,nosuid "/dev/mapper/$bname" "$mountpath"
When I open a new subterminal from the terminal that run the script, I can see the mount and access the files in it. But when I open another terminal I don't see anything from the mount and the mountpoint-directory is empty. (Both at the same time). It seems that the mount has something like a scope.
I googled around but didn't find anything… So what's causing this? And how to handle/disable it?
Thanks in advance!
Offline
The script does stuff
Like chroot "stuff"?
Please provide the actual "stuff" you use, because there is otherwise no way to make an informed statement on your issue.
Offline
But when I open another terminal I don't see anything from the mount and the mountpoint-directory is empty.
How exactly are you referring to the dir? Hopefully *not* by referring to the $mountpath variable.
Offline
The script does stuff
Like chroot "stuff"?
Please provide the actual "stuff" you use, because there is otherwise no way to make an informed statement on your issue.
Nope nothing about chroot, containers or namespaces. Mostly dealing with user-input and local files the only thing related to the mount is:
loopdev=$(losetup -f)
losetup "$loopdev" "$tcfile"
tcplay --veracrypt-mode -m "$bname" -d "$loopdev"
mount -o defaults,nodev,nosuid "/dev/mapper/$bname" "$mountpath"
Nudin wrote:But when I open another terminal I don't see anything from the mount and the mountpoint-directory is empty.
How exactly are you referring to the dir? Hopefully *not* by referring to the $mountpath variable.
No, of course not but by absolute path. But the point is, if I look at the output of mount it is listed in the original terminal but not listed in other terminals.
Offline
Would you prettyplease provide the *entire* script?
Does your script behave likewise when mounting an ordinary device (no loop, no truecrypt)?
Do you look at the ("failed") mounts from a root shell or with your daily user?
Offline
The original version of the script was quite long, but I striped it down to a "minimal working example" – means the bug occurs with this script:
#!/bin/bash
#set -x
open()
{
loopdev=$(losetup -f)
bname=$(basename "$tcfile")
losetup "$loopdev" "$tcfile" && \
tcplay --veracrypt-mode -m "$bname" -d "$loopdev" || return
sleep 1
if [ $(blkid -o value -s TYPE "/dev/mapper/$bname") = "vfat" ] ; then
mount -o defaults,nodev,nosuid,umask=000 "/dev/mapper/$bname" "$mountpath"
else
mount -o defaults,nodev,nosuid "/dev/mapper/$bname" "$mountpath"
fi
echo "Mounted successfully"
}
mountpath=/media/truecrypt/
# Make sure only root can run our script
if [ "$(id -u)" != "0" ]; then
echo "This script must be run as root" 1>&2
exit 1
fi
tcfile=/mnt/MEDIA/most.tc
open
read
And no – the mount isn't visible as root as well. In fact the content of /etc/mtab is different depending on wich terminal I am in…
Terminal 1:
$ sudo mount | grep truecrypt
/dev/mapper/most.tc on /media/truecrypt type ext3 (rw,nosuid,nodev,relatime,data=ordered)
$ sudo grep truecrypt /etc/mtab
/dev/mapper/most.tc /media/truecrypt ext3 rw,nosuid,nodev,relatime,data=ordered 0 0
Terminal 2:
$ grep truecrypt /etc/mtab
$ sudo grep truecrypt /etc/mtab
It only occurs if I start the script via desktop-icon, coudn't reproduce it if I start it in terminal myself.
Offline
It only occurs if I start the script via desktop-icon, coudn't reproduce it if I start it in terminal myself.
What? Then what are the two terminals you are contrasting the output from? If you run the script from a terminal, it works. If you run it from a .desktop file it fails. Is that what you are now telling us?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
If I run it from a terminal -> everything is ok and normal.
If I run it via the .desktop-file witch is set up that way, that it will run the script within a Gnome-Terminal – and after the script prints out "Mounted successfully" (but doesn't exit because of the 'read' in the last line), open a new tab in this Gnome-Terminal, I see the mount and can access it. (→ Listing Terminal 1) I can also access it via other terminal, witch I start from this terminal.
If at the same time (without closing the Gnome-Terminal in witch the script ran), I open another Terminalemulator (xterm, Gnome-Terminal, whatever) I can not see the mount. I can also not see the mount on tty3, not via root, etc. – it is vissible only in sub processes spawned by the Gnome-Terminal in witch the script ran!
I hope you now finally understand the issue and why this is confusing me so much!
My current theory is that the DE runs the exec from the .desktop in unshared namespaces, but I can't verify that. Other suspects would be cgroups (but there are none), systemd or linux-hardend.
Some screnshots to demonstration:
https://pasteboard.co/GIqbB24.jpg
https://pasteboard.co/GIq74EU.jpg
Last edited by Nudin (2017-09-01 23:56:39)
Offline
Ah, thanks - that makes sense (in that I understand what you're describing). As to the cause - that still makes no sense.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
or linux-hardend
Being in use? What happens with the vanilla kernel? (linux or linux-lts)
This behavior mandates process separation which cannot be explained by a (the) bash script or its invocation - and namespaces are not activated in the vanilla config of arch linux.
Offline
My current theory is that the DE runs the exec from the .desktop in unshared namespaces, but I can't verify that.
Does sound like it, and of course you can verify it since you can have two shells:
readlink /proc/$$/ns/mnt
If they differ then indeed they're in two different mount namespaces.
Offline
Sorry was busy the last days…
Being in use? What happens with the vanilla kernel? (linux or linux-lts)
Tested: Happens also with vanilla kernel (linux).
Nudin wrote:My current theory is that the DE runs the exec from the .desktop in unshared namespaces, but I can't verify that.
Does sound like it, and of course you can verify it since you can have two shells:
readlink /proc/$$/ns/mnt
If they differ then indeed they're in two different mount namespaces.
Thanks, didn't knew this! And indeed they differ! So this seems to be the puzzles solution…
I don't see any way to circumvent this and have a button mounting the partition – anyone?
Offline
I don't see any way to circumvent this and have a button mounting the partition – anyone?
Ideally you'd figure out why your script runs in (a) different namespace(s), and turn it off. Otherwise as some ugly workaround I guess you could use nsenter in your script, to make sure it runs in the correct namespace, whichever that may be.
E.g. you could do
nsenter -t1 -m -- mount ...
to make sure the mount happens inside the same mount namespace as that of PID1, assuming that is the right one of course.
Offline
Pages: 1