mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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 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).