* [musl] getmntent() fails to parse when source is empty string
@ 2022-04-05 17:09 Keyu Tao
2022-04-10 16:00 ` Alex Xu (Hello71)
0 siblings, 1 reply; 3+ messages in thread
From: Keyu Tao @ 2022-04-05 17:09 UTC (permalink / raw)
To: musl
Hi,
The first argument (const char *source) of mount(2) can be an empty
string like this:
mount("", "/tmp/test1", "tmpfs", MS_NODEV | MS_NOSUID, NULL);
After mounting in Linux, the /etc/mtab shows this mountpoint like:
/tmp/test1 tmpfs rw,nosuid,nodev,relatime,inode64 0 0
However, getmntent_r() in musl (in L42 of root/src/misc/mntent.c) uses
sscanf() to parse mounted filesystem description:
cnt = sscanf(linebuf, " %n%*s%n %n%*s%n %n%*s%n %n%*s%n %d %d", ...)
When parsing the weird mountpoint, the value of cnt is 1: the mountpoint
gets ignored and the do-while loop continues. I'm wondering whether it
would be considered as a bug of musl.
Thank you.
(P.S: I'm not subscribed to the mail list and I would like to be Cc'd on
replies)
===
Reproduction (in an Alpine 3.15 container on Debian 11, kernel version =
5.15.0-0.bpo.3-amd64):
$ sudo docker run -it --rm --privileged -v /tmp:/test alpine:3.15
/ # apk add build-base
/ # cat /test/mount.c
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <errno.h>
#include <stdio.h>
int main(void) {
int ret = mkdir("/tmp/test1", 0777);
if (ret && errno != EEXIST) {
perror("mkdir (1)");
}
ret = mount("", "/tmp/test1", "tmpfs", MS_NODEV | MS_NOSUID, NULL);
if (ret) {
perror("mount (1)");
}
ret = mkdir("/tmp/test2", 0777);
if (ret && errno != EEXIST) {
perror("mkdir (2)");
}
ret = mount(NULL, "/tmp/test2", "tmpfs", MS_NODEV | MS_NOSUID, NULL);
if (ret) {
perror("mount (2)");
}
// umount("/tmp/test1");
// umount("/tmp/test2");
return 0;
}
/ # gcc /test/mount.c
/ # ./a.out
/ # mount
(other mountpoints omitted)
devpts on /dev/console type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
none on /tmp/test2 type tmpfs (rw,nosuid,nodev,relatime,inode64)
/ # cat /etc/mtab
(other mountpoints omitted)
devpts /dev/console devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
/tmp/test1 tmpfs rw,nosuid,nodev,relatime,inode64 0 0
none /tmp/test2 tmpfs rw,nosuid,nodev,relatime,inode64 0 0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] getmntent() fails to parse when source is empty string
2022-04-05 17:09 [musl] getmntent() fails to parse when source is empty string Keyu Tao
@ 2022-04-10 16:00 ` Alex Xu (Hello71)
2022-04-10 16:39 ` Keyu Tao
0 siblings, 1 reply; 3+ messages in thread
From: Alex Xu (Hello71) @ 2022-04-10 16:00 UTC (permalink / raw)
To: musl; +Cc: Keyu Tao
It's worth noting that octal escape sequences are also not supported.
This has been reported previously, e.g. at:
https://inbox.vuxu.org/musl/HE1P192MB0010D60AAC4BA0F08F1A5644FB5E0@HE1P192MB0010.EURP192.PROD.OUTLOOK.COM/
https://inbox.vuxu.org/musl/87o85j8sru.fsf@atufi.org/
I think the empty source is basically impossible to support with
getmntent though. Both the glibc and musl implementations ignore leading
whitespace, probably because getmntent is more commonly used with fstab,
where users may have unintentional leading whitespace. If empty sources
are an issue for your program, I would suggest using your own getmntent
implementation.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] getmntent() fails to parse when source is empty string
2022-04-10 16:00 ` Alex Xu (Hello71)
@ 2022-04-10 16:39 ` Keyu Tao
0 siblings, 0 replies; 3+ messages in thread
From: Keyu Tao @ 2022-04-10 16:39 UTC (permalink / raw)
To: musl; +Cc: alex_y_xu
Thank you for your reply.
I once believed that glibc can handle the leading whitespace as `mount`
in my host is working correctly. I rechecked just now and found that the
`mount` in Alpine container is provided by busybox, which uses
`getmntent_r()` to parse /proc/mounts (in mount_main()). However, the
`mount` in my host is provided by util-linux package rather than
busybox, and it does not use `getmntent()`. I used `ltrace` to see all
library function calls, and the busybox mount implementation in glibc
also provides incorrect result like this:
getmntent_r(0x555adeefa2c0, { "/tmp/test1", "tmpfs",
"rw,nosuid,nodev,relatime,inode64"..., "0", 0, 0 }, " /tmp/test1", 1016)
= { "/tmp/test1", "tmpfs", "rw,nosuid,nodev,relatime,inode64"..., "0",
0, 0 }
getmntent_r(0x555adeefa2c0, { "none", "/tmp/test2", "tmpfs",
"rw,nosuid,nodev,relatime,inode64"..., 0, 0 }, "none", 1016) = { "none",
"/tmp/test2", "tmpfs", "rw,nosuid,nodev,relatime,inode64"..., 0, 0 }
It looks like not a bug of musl now :-).
在 2022/4/11 00:00, Alex Xu (Hello71) 写道:
> It's worth noting that octal escape sequences are also not supported.
> This has been reported previously, e.g. at:
>
> https://inbox.vuxu.org/musl/HE1P192MB0010D60AAC4BA0F08F1A5644FB5E0@HE1P192MB0010.EURP192.PROD.OUTLOOK.COM/
>
> https://inbox.vuxu.org/musl/87o85j8sru.fsf@atufi.org/
>
> I think the empty source is basically impossible to support with
> getmntent though. Both the glibc and musl implementations ignore leading
> whitespace, probably because getmntent is more commonly used with fstab,
> where users may have unintentional leading whitespace. If empty sources
> are an issue for your program, I would suggest using your own getmntent
> implementation.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-04-10 21:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-05 17:09 [musl] getmntent() fails to parse when source is empty string Keyu Tao
2022-04-10 16:00 ` Alex Xu (Hello71)
2022-04-10 16:39 ` Keyu Tao
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).