Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Am 01.08.2016 um 15:33 schrieb Andreas Henriksson: > Hello again Ingo. > > On Mon, Jul 25, 2016 at 10:13:29AM +0200, Ingo wrote: >> Am 24.07.2016 um 22:07 schrieb Andreas Henriksson: >>> >>> Are you sure this is the correct syntax? I would expect that you >>> should specify the mountpoint (target directory) rather than the >>> source of the mount. eg. mount /home/ingo/leo.Bilder >>> Do using that still give you the same problem? >> >> Great, at least that works as expected if target directory is used. >> >> But "man mount" explicitely states: > [...] > > You're right, the manpage explicitly says in multiple places > that what you're doing should work... I'm still thinking ... ... to adjust the manpages? > using the mountpoint is always preferrable/recommended though. ;) > > I got a chance to discuss this with upstream and I'll try to summarize > some of the useful information here for the record (and as a personal > reminder for the future): > > > Despite knowing where we stumble, it's not easy to come up with a solution > that suites both the people who wants to avoid path disclosure and your > usecase. Given you now know about using the mountpoint (which also > upstream said is really the way to go when specifying mounts, rather > than the source) would you agree that this isn't strictly Release Critical > severity anymore? I do agree! Thanks to your explanation I understand the background and will change my habits. > > Hopefully everything works as you expect it to when you mount as non-root > using "mount /mountpoint" or did you see any additional problems with that? No further problems here with NFSv4 mounts, I won't forget what I have learned with this bug. Regards, Ingo
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Hello again Ingo.
On Mon, Jul 25, 2016 at 10:13:29AM +0200, Ingo wrote:
> Am 24.07.2016 um 22:07 schrieb Andreas Henriksson:
> >
> > Are you sure this is the correct syntax? I would expect that you
> > should specify the mountpoint (target directory) rather than the
> > source of the mount. eg. mount /home/ingo/leo.Bilder
> > Do using that still give you the same problem?
>
> Great, at least that works as expected if target directory is used.
>
> But "man mount" explicitely states:
[...]
You're right, the manpage explicitly says in multiple places
that what you're doing should work... I'm still thinking
using the mountpoint is always preferrable/recommended though. ;)
I got a chance to discuss this with upstream and I'll try to summarize
some of the useful information here for the record (and as a personal
reminder for the future):
In sys-utils/mount.c in the main() function there's this code
that catches when you only provide one argument as in e.g.
"mount leo:/Bilder" :
} else if (argc == 1 && (!mnt_context_get_source(cxt) ||
!mnt_context_get_target(cxt))) {
...
else
mnt_context_set_target(cxt, argv[0]);
Which means the argument you provide (leo:/Bilder) always ends up
in the "target" field, but there's code in libmount which handles
trying it both as the source and target for fstab matching in
libmount/src/context.c apply_table() function:
if (!fs && mnt_context_is_swapmatch(cxt)) {
...
if (!fs && tgt)
fs = mnt_table_find_source(tb, tgt, direction);
Unfortunately when you run the mount command as non-root you never
get that far, because you get stuck much earlier where there's
security sensitive code that tries to prevent you from using mount
to check if directories exists which your user has no access to check.
See again sys-utils/mount.c main() function:
if (mnt_context_is_restricted(cxt))
sanitize_paths(cxt);
The sanitize_paths() will call into canonicalize_path_restricted()
and error out when the path you gave can't be expanded using
realpath().
The canonicalize_path_restricted() function can be found in
lib/canonicalize.c.
The seteuid/setegid calls in canonicalize_path_restricted() can
be seen in the strace output (followed by the error message):
...
| 09:54:06.494259 getgid()= 1000
| 09:54:06.494287 setresgid(-1, 1000, -1) = 0
| 09:54:06.494318 getuid()= 1000
| 09:54:06.494345 setresuid(-1, 1000, -1) = 0
| 09:54:06.494384 getcwd("/home/ingo", 4096) = 11
| 09:54:06.494415 lstat("/home/ingo/leo:", 0x7ffca08ba150) = -1 ENOENT (No such
file or directory)
| 09:54:06.494450 setresgid(-1, 1000, -1) = 0
| 09:54:06.494478 setresuid(-1, 1000, -1) = 0
| 09:54:06.494515 write(2, "mount: ", 7mount: ) = 7
| 09:54:06.494547 write(2, "leo:/Bilder", 11leo:/Bilder) = 11
| 09:54:06.494577 write(2, ": ", 2: ) = 2
...
| 09:54:06.495331 write(2, "Datei oder Verzeichnis nicht gef"..., 38Datei
| oder Verzeichnis nicht gefunden
| ) = 38
...
(Btw, the strace you provided proved to be very useful!)
(The reason this all works when running as root is because then
sanitize_paths is not called at all because of the condition
on mnt_context_is_restricted(cxt) in that case.)
Despite knowing where we stumble, it's not easy to come up with a solution
that suites both the people who wants to avoid path disclosure and your
usecase. Given you now know about using the mountpoint (which also
upstream said is really the way to go when specifying mounts, rather
than the source) would you agree that this isn't strictly Release Critical
severity anymore?
Hopefully everything works as you expect it to when you mount as non-root
using "mount /mountpoint" or did you see any additional problems with that?
(Btw, if you're seeing problems with umount maybe this recent post on
the upstream mailing list and the followup is interesting to you:
http://www.spinics.net/lists/util-linux-ng/msg13078.html )
Upstream mentioned further investigating this problem is now on his TODO.
Regards,
Andreas Henriksson
PS. fwiw, the mount utility in >= Jessie is a complete rewrite compared to
the one shipped in <= Wheezy. It's now based on the new libmount which is
why the new utility is smaller than the old one (not counting size of
dynamically linked libraries).
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Some additional Information which probably helps to find the root cause: The very same beheaviour (as in Jessie) is still shown in Stretch. I already tried to assign that bug to package "mount", but this was not accepted. The corresponding bug report demonstrates some more possibilities of "how you can workaroung" this faulty beheaviour. See here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788547#12
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Am 24.07.2016 um 22:07 schrieb Andreas Henriksson:
>
> Are you sure this is the correct syntax? I would expect that you
> should specify the mountpoint (target directory) rather than the
> source of the mount. eg. mount /home/ingo/leo.Bilder
> Do using that still give you the same problem?
Great, at least that works as expected if target directory is used.
But "man mount" explicitely states:
"When mounting a filesystem mentioned in fstab or mtab, it suffices to
give only the device, or only the mount point."
Moreover my syntax (using the device/source has worked flawlewssly since
I am using Linux. In Debian I use it since Lenny! And it works if the
command is issued as 'root'.
>
> Might also be useful to have a log of what strace tells you about
> running the command.
For completenes here the stace output:
~$ strace -Ff -tt mount leo:/Bilder 2>&1 | tee strace-mount.log
09:54:06.486801 execve("/bin/mount", ["mount", "leo:/Bilder"], [/* 36
vars */]) = 0
09:54:06.487198 brk(0) = 0x1295000
09:54:06.487350 fcntl(0, F_GETFD) = 0
09:54:06.487410 fcntl(1, F_GETFD) = 0
09:54:06.487438 fcntl(2, F_GETFD) = 0
09:54:06.487465 access("/etc/suid-debug", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.487533 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.487571 mmap(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4315787000
09:54:06.487629 access("/etc/ld.so.preload", R_OK) = 0
09:54:06.487704 open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
09:54:06.487742 fstat(3, {st_mode=S_IFREG|0644, st_size=28, ...}) = 0
09:54:06.48 mmap(NULL, 28, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0)
= 0x7f4315786000
09:54:06.487810 close(3)= 0
09:54:06.487846 open("/opt/lib/libmediaclient.so", O_RDONLY|O_CLOEXEC) = 3
09:54:06.487880 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\35\0\0\0\0\0\0"...,
832) = 832
09:54:06.487914 fstat(3, {st_mode=S_IFREG|0755, st_size=64168, ...}) = 0
09:54:06.487948 mmap(NULL, 2161808, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4315359000
09:54:06.487981 mprotect(0x7f4315368000, 2093056, PROT_NONE) = 0
09:54:06.488017 mmap(0x7f4315567000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7f4315567000
09:54:06.488061 close(3)= 0
09:54:06.488094 munmap(0x7f4315786000, 28) = 0
09:54:06.488130 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
09:54:06.488163 fstat(3, {st_mode=S_IFREG|0644, st_size=144332, ...}) = 0
09:54:06.488195 mmap(NULL, 144332, PROT_READ, MAP_PRIVATE, 3, 0) =
0x7f4315763000
09:54:06.488227 close(3)= 0
09:54:06.488259 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488297 open("/lib/x86_64-linux-gnu/libmount.so.1",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488333 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\254\0\0\0\0\0\0"...,
832) = 832
09:54:06.488366 fstat(3, {st_mode=S_IFREG|0644, st_size=284096, ...}) = 0
09:54:06.488400 mmap(NULL, 2383648, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4315113000
09:54:06.488432 mprotect(0x7f4315156000, 2097152, PROT_NONE) = 0
09:54:06.488465 mmap(0x7f4315356000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x43000) = 0x7f4315356000
09:54:06.488504 mmap(0x7f4315358000, 3872, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4315358000
09:54:06.488542 close(3)= 0
09:54:06.488577 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488611 open("/lib/x86_64-linux-gnu/libselinux.so.1",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488644 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20c\0\0\0\0\0\0"...,
832) = 832
09:54:06.488677 fstat(3, {st_mode=S_IFREG|0644, st_size=142728, ...}) = 0
09:54:06.488709 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4315762000
09:54:06.488745 mmap(NULL, 2246896, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4314eee000
09:54:06.488777 mprotect(0x7f4314f0f000, 2097152, PROT_NONE) = 0
09:54:06.488814 mmap(0x7f431510f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0x7f431510f000
09:54:06.488852 mmap(0x7f4315111000, 6384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4315111000
09:54:06.488890 close(3)= 0
09:54:06.488924 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488960 open("/lib/x86_64-linux-gnu/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488995 read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"...,
832) = 832
09:54:06.489028 fstat(3, {st_mode=S_IFREG|0755, st_size=1738176, ...}) = 0
09:54:06.489061 mmap(NULL, 3844640, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4314b43000
09:54:06.489094 mprotect(0x7f4314ce5000, 2093056, PROT_NONE) = 0
09:54:06.489128 mmap(0x7f4314ee4000,
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Hello Ingo. On Fri, Jun 12, 2015 at 06:12:21PM +0200, Ingo wrote: > Since upgrade of the client from Wheezy to Jessie I am no longer able to > mount nfs4-exports from a host (leo) running Wheezy as a normal user > (UID=1000): [...] > /etc/fstab entries on the clients (Jessi and Wheezy): > leo:/Bilder /home/ingo/leo.Bilder nfs4 noauto,rw,user,soft,relatime 0 0 > > In Wheezy all works as expected, in Jessie mount fails with: > $ LANG=en_US.UTF-8 mount leo:/Bilder > mount: leo:/Bilder: No such file or directory Are you sure this is the correct syntax? I would expect that you should specify the mountpoint (target directory) rather than the source of the mount. eg. mount /home/ingo/leo.Bilder Do using that still give you the same problem? Might also be useful to have a log of what strace tells you about running the command. > > However it is possible to perform the mount as "root". > > Umount as user (UID=1000) fails with same "non informative" message: > $ LANG=en_US.UTF-8 umount leo:/Bilder > umount: leo:/Bilder: No such file or directory > > This is a security flaw as users cannot mount/umount on demand without > root-privileges. (Well, it's not a security issue unless you hand out root access yourself to untrusted people.) Regards, Andreas Henriksson
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Hallo Ingo, konntest Du das Problem lösen? Es liegt an den locales! Man hat den selben Effekt mit einr nichtsagenden Message, wenn man mit sftp auf den Host geht: No such file or directory dpkg-reconfigure locales auf dem Host hilft Jessie auf die Beine. Ween man auf beiden Hosts exakt die gleiche Zeichennsätze aktiviert. Default braucht man nicht (keine). Habe lange gebraucht, um das Problem einzukreisen. On Fri, 12 Jun 2015 18:12:21 +0200 Ingo wrote: > Package: nfs-common > Version: 1:1.2.8-9 > Severity: severe > > Since upgrade of the client from Wheezy to Jessie I am no longer able to > mount nfs4-exports from a host (leo) running Wheezy as a normal user > (UID=1000): > > # showmount -e leo > Export list for leo: > /srv/nfs4/Bilder 192.168.33.0/24 > /srv/nfs4192.168.33.0/24 > > > /etc/fstab entries on the clients (Jessi and Wheezy): > leo:/Bilder /home/ingo/leo.Bilder nfs4 noauto,rw,user,soft,relatime 0 0 > > In Wheezy all works as expected, in Jessie mount fails with: > $ LANG=en_US.UTF-8 mount leo:/Bilder > mount: leo:/Bilder: No such file or directory > > However it is possible to perform the mount as "root". > > Umount as user (UID=1000) fails with same "non informative" message: > $ LANG=en_US.UTF-8 umount leo:/Bilder > umount: leo:/Bilder: No such file or directory > > This is a security flaw as users cannot mount/umount on demand without > root-privileges. > > Mit freundlichen Grüßen / Kind Regards / cordialement Peter Franke -- Systemverwaltung der Fachrichtung 6.1 (Mathematik) Universität des Saarlandes Gebäude E2.4, Zimmer 4.14 66123 Saarbrücken tel +49-681-302-4016 fax +49-681-302-79-4016 e-mail systemverwalt...@math.uni-sb.de www http://service.math.uni-sb.de
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Package: nfs-common Version: 1:1.2.8-9 Severity: severe Since upgrade of the client from Wheezy to Jessie I am no longer able to mount nfs4-exports from a host (leo) running Wheezy as a normal user (UID=1000): # showmount -e leo Export list for leo: /srv/nfs4/Bilder 192.168.33.0/24 /srv/nfs4192.168.33.0/24 /etc/fstab entries on the clients (Jessi and Wheezy): leo:/Bilder /home/ingo/leo.Bilder nfs4 noauto,rw,user,soft,relatime 0 0 In Wheezy all works as expected, in Jessie mount fails with: $ LANG=en_US.UTF-8 mount leo:/Bilder mount: leo:/Bilder: No such file or directory However it is possible to perform the mount as "root". Umount as user (UID=1000) fails with same "non informative" message: $ LANG=en_US.UTF-8 umount leo:/Bilder umount: leo:/Bilder: No such file or directory This is a security flaw as users cannot mount/umount on demand without root-privileges. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
