proxy-defpager for all users?

[Samuel Thibault]

Hello,

proxy-defpager is typically set on /servers/default-pager, but its
permissions are by default 644, which makes it unusable by normal users,
it'd need to be 755 (see the x check in the defpager source).

Apart from allowing users to eat memory, which they currently already
can do anyway, is there any downside to making this 755 so people can
mount their own tmpfs?

Samuel

[Richard Braun]

Post by Samuel Thibault
proxy-defpager is typically set on /servers/default-pager, but its
permissions are by default 644, which makes it unusable by normal users,
it'd need to be 755 (see the x check in the defpager source).
Apart from allowing users to eat memory, which they currently already
can do anyway, is there any downside to making this 755 so people can
mount their own tmpfs?

I personally wondered why it wasn't the case from the start.

That being said, I'll use this as an opportunity to restate a core
problem of Mach memory management, as I couldn't find it on the wiki.
This problem may or may not be even more triggered by using unprivileged
tmpfs instances.

Thu Dec 29 2016 :
< braunr> i've identified a fundamental flaw with the default pager
< braunr> and actually, with mach in general i suppose
< braunr> i assumed that it was necessary to trust the server only
< braunr> that a server didn't need to trust its client
< braunr> but mach messages carry memory that is potentially mapped from unprivileged pagers
< braunr> which means faulting on that memory effectively makes the faulting process a client to the unprivileged pager
< braunr> and that's something that can happen to the default pager during heavy memory pressure
< braunr> in which case it deadlocks on itself because the copyout hangs on a fault, waiting for the unprivileged pager to provide the data
< braunr> (which it can't because of heavy memory pressure and because it's unprivileged, it's blocked, waiting until allocations resume)
< braunr> the pageout daemon will keep paging out to the default pager in the hope those pages get freed
< braunr> but sending to the default pager is now impossible because its map is locked on the never-ending fault

[Samuel Thibault]

Post by Richard Braun

Post by Samuel Thibault
proxy-defpager is typically set on /servers/default-pager, but its
permissions are by default 644, which makes it unusable by normal users,
it'd need to be 755 (see the x check in the defpager source).
Apart from allowing users to eat memory, which they currently already
can do anyway, is there any downside to making this 755 so people can
mount their own tmpfs?

I personally wondered why it wasn't the case from the start.
That being said, I'll use this as an opportunity to restate a core
problem of Mach memory management, as I couldn't find it on the wiki.
This problem may or may not be even more triggered by using unprivileged
tmpfs instances.

I actually encountered such an issue with php7.3's shm testing, which
triggers an ext2fs crash due to a tmpfs issue. I'll probably add the
attached patch to the debian package for now, but it seems that the
server side of RPCs needs to be more careful about receiving data when
it's passed out of line.

Samuel

[Joshua Branson]

Post by Richard Braun

Post by Samuel Thibault
proxy-defpager is typically set on /servers/default-pager, but its
permissions are by default 644, which makes it unusable by normal users,
it'd need to be 755 (see the x check in the defpager source).
Apart from allowing users to eat memory, which they currently already
can do anyway, is there any downside to making this 755 so people can
mount their own tmpfs?

I personally wondered why it wasn't the case from the start.
That being said, I'll use this as an opportunity to restate a core
problem of Mach memory management, as I couldn't find it on the wiki.
This problem may or may not be even more triggered by using unprivileged
tmpfs instances.

I'll add this information to the wiki in a few days.

Post by Richard Braun
< braunr> i've identified a fundamental flaw with the default pager
< braunr> and actually, with mach in general i suppose
< braunr> i assumed that it was necessary to trust the server only
< braunr> that a server didn't need to trust its client
< braunr> but mach messages carry memory that is potentially mapped from unprivileged pagers
< braunr> which means faulting on that memory effectively makes the faulting process a client to the unprivileged pager
< braunr> and that's something that can happen to the default pager during heavy memory pressure
< braunr> in which case it deadlocks on itself because the copyout hangs on a fault, waiting for the unprivileged pager to provide the data
< braunr> (which it can't because of heavy memory pressure and because it's unprivileged, it's blocked, waiting until allocations resume)
< braunr> the pageout daemon will keep paging out to the default pager in the hope those pages get freed
< braunr> but sending to the default pager is now impossible because its map is locked on the never-ending fault

[Samuel Thibault]

Post by Richard Braun

Post by Samuel Thibault
proxy-defpager is typically set on /servers/default-pager, but its
permissions are by default 644, which makes it unusable by normal users,
it'd need to be 755 (see the x check in the defpager source).
Apart from allowing users to eat memory, which they currently already
can do anyway, is there any downside to making this 755 so people can
mount their own tmpfs?

I personally wondered why it wasn't the case from the start.

Most probably because we didn't realize we had to make it +x to make it
usable by users.

Samuel