Re: [systemd-devel] users and per user limits (tmpfs)
On Tue, Apr 28, 2015 at 1:39 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 28.04.15 13:17, Mantas Mikulėnas (graw...@gmail.com) wrote: Moreover, when this is set up the mount propagation from the user's namespace to the rest of system must be turned off for the root directory, and this will break general assumptions around mounting things through tools like su or sudo then, as those mounts will not propagate to the rest of the system either... Wondering how the existing pam_namespace deals with this. Maybe / could be kept shared, just /tmp made private. No, the propagation rules control if submounts of a mount are propagated. If you intend to mount something on /tmp, then the propagation rules of / are the ones that matter. I mean when /tmp itself is already a mountpoint, e.g. a bind mount on top of itself (a common hack), then it has its own propagation mode, which will be honored when mounting something at /tmp too, not just underneath. (out) mount --bind /tmp /tmp (out) mount --make-private /tmp (out) unshare --mount (in) mount -t tmpfs none /tmp (outin) findmnt Really unnecessarily complex, but possible. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] users and per user limits (tmpfs)
On Tue, 28.04.15 13:49, Mantas Mikulėnas (graw...@gmail.com) wrote: On Tue, Apr 28, 2015 at 1:39 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 28.04.15 13:17, Mantas Mikulėnas (graw...@gmail.com) wrote: Moreover, when this is set up the mount propagation from the user's namespace to the rest of system must be turned off for the root directory, and this will break general assumptions around mounting things through tools like su or sudo then, as those mounts will not propagate to the rest of the system either... Wondering how the existing pam_namespace deals with this. Maybe / could be kept shared, just /tmp made private. No, the propagation rules control if submounts of a mount are propagated. If you intend to mount something on /tmp, then the propagation rules of / are the ones that matter. I mean when /tmp itself is already a mountpoint, e.g. a bind mount on top of itself (a common hack), then it has its own propagation mode, which will be honored when mounting something at /tmp too, not just underneath. (out) mount --bind /tmp /tmp (out) mount --make-private /tmp (out) unshare --mount (in) mount -t tmpfs none /tmp (outin) findmnt Really unnecessarily complex, but possible. To my knowledge this is not how this works. If you overmount an existing mount it's the parent mount and not the old mount whose propagation matters. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] users and per user limits (tmpfs)
On Tue, Apr 28, 2015 at 1:06 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 28.04.15 12:03, Michał Zegan (webczat_...@poczta.onet.pl) wrote: (sorry, I haven't sent a reply to the list) What about namespacing and mounting tmpfs per user? You can specify a filesystem size when mounting tmpfs can't you? Well, you can set this up with some packages for individual systems, but this cannot work for general purpose systems since X11 uses /tmp for placing its communication sockets. That *should* work as long as the X server itself is started by the same user (GDM 3.16 works that way because of Wayland, as does startx). Moreover, when this is set up the mount propagation from the user's namespace to the rest of system must be turned off for the root directory, and this will break general assumptions around mounting things through tools like su or sudo then, as those mounts will not propagate to the rest of the system either... Wondering how the existing pam_namespace deals with this. Maybe / could be kept shared, just /tmp made private. I don't really like the idea of littering regular systems with even more tangled mount namespaces, but still curious if this could work. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] users and per user limits (tmpfs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It may be possible, actually. Why oh why btrfs has no per user quotas? this would be beneficial in some scenarios like this one. W dniu 2015-04-28 o 12:17, Mantas Mikulėnas pisze: On Tue, Apr 28, 2015 at 1:06 PM, Lennart Poettering lenn...@poettering.net mailto:lenn...@poettering.net wrote: On Tue, 28.04.15 12:03, Michał Zegan (webczat_...@poczta.onet.pl mailto:webczat_...@poczta.onet.pl) wrote: (sorry, I haven't sent a reply to the list) What about namespacing and mounting tmpfs per user? You can specify a filesystem size when mounting tmpfs can't you? Well, you can set this up with some packages for individual systems, but this cannot work for general purpose systems since X11 uses /tmp for placing its communication sockets. That /should/ work as long as the X server itself is started by the same user (GDM 3.16 works that way because of Wayland, as does startx). Moreover, when this is set up the mount propagation from the user's namespace to the rest of system must be turned off for the root directory, and this will break general assumptions around mounting things through tools like su or sudo then, as those mounts will not propagate to the rest of the system either... Wondering how the existing pam_namespace deals with this. Maybe / could be kept shared, just /tmp made private. I don't really like the idea of littering regular systems with even more tangled mount namespaces, but still curious if this could work. -- Mantas Mikulėnas graw...@gmail.com mailto:graw...@gmail.com -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVP17NAAoJEHb1CzgxXKwYppQP/3FQ68SBzE1GpN2hCEgsXHIa +gP6MsGwnsMppXD0wlfEuu55k4mmfm9unZ6c/+fwA+iTPIhVQceUAyj2X4euhzo/ jEzs7v05BiO9dVp+ZUPrgn9JLkJ67ve83f0rIgQgM4niXolK0gRhNUcT056V78Lk tWxqqJ1rY6MSlCWVQNbNgxy5c+gK5J3sKPNbDscTh4iI/usPSkfWYFfLIi5PwKOA 33I47SRzhJ4RuUs6znNJNhitb/bpD6WyWQVyo+NaPDt/iTFNsGeIndYF7YoL36BY bo3Xuc8B4whQDV6W82EIWDT7gF5FP/G8cu4Z9w3e+f0Il8h5nEjltyVewWHpHaaK KpBYQ09URZqLjdDbeN8A2Ay3laMa5PrXesBHQ10jCLkDYNQm4M4yS1hcLjKzsECj huzUGYmx00Bm2C15CR8JK56NFGT2tNmg+LOTqgVSoSZ4Qe5WpyHpzK3CViFkC9q9 IB+6lHnKn8FEZKw9SD+rr/o1qyGdDY0KeePT4eBRElyOeip4+gcQjM8PpDbximUm Cidm/ymvJ64sUbjhHkoclLFMfQIS6Jhx2BcTwa/cf0L9Y1OYBOCKm2KYoRKe55qN N5lM2x54gPs8nrmM3nu7zfsHQluPRIuPCkJ2r+BrgAf4RQmqGgdl/5J5kmSdwdIq 5ZfVSo3syK0QjvtBxhCN =4bV+ -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] users and per user limits (tmpfs)
On Tue, 28.04.15 12:11, Michał Zegan (webczat_...@poczta.onet.pl) wrote: What if I will just make the / and similar mounts shared? You have to turn off mount propagation for /tmp, so that the per-user /tmp instance is not propagated to the rest of the system. But after turning this off you cannot turn it on anymore, that's how the kernel works. Which means if thereafter you try to mount something over /mnt, then this will also not propagate to the rest of the sytem. Well, I am not entirely sure about this whole terminology, not sure if I understand it. About x11, in case of gnome I think a second x server is spawned to service a request in context of a session (gnome 3.16) so not sure if it would be a problem. Anyway something like on-disk tmpfs with quotas may be safer/maybe easier to understand. The X11 socket is used for communication between users, hence poly-instantiated /tmp will break some of X11 uses. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] users and per user limits (tmpfs)
On Tue, 28.04.15 13:17, Mantas Mikulėnas (graw...@gmail.com) wrote: Moreover, when this is set up the mount propagation from the user's namespace to the rest of system must be turned off for the root directory, and this will break general assumptions around mounting things through tools like su or sudo then, as those mounts will not propagate to the rest of the system either... Wondering how the existing pam_namespace deals with this. Maybe / could be kept shared, just /tmp made private. No, the propagation rules control if submounts of a mount are propagated. If you intend to mount something on /tmp, then the propagation rules of / are the ones that matter. Also, if you disconnected propagation between two mount namespaces you cannot reestablish the anymore. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] users and per user limits (tmpfs)
On Tue, 28.04.15 12:03, Michał Zegan (webczat_...@poczta.onet.pl) wrote: (sorry, I haven't sent a reply to the list) What about namespacing and mounting tmpfs per user? You can specify a filesystem size when mounting tmpfs can't you? Well, you can set this up with some packages for individual systems, but this cannot work for general purpose systems since X11 uses /tmp for placing its communication sockets. Moreover, when this is set up the mount propagation from the user's namespace to the rest of system must be turned off for the root directory, and this will break general assumptions around mounting things through tools like su or sudo then, as those mounts will not propagate to the rest of the system either... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] users and per user limits (tmpfs)
On Tue, 28.04.15 00:55, Michał Zegan (webczat_...@poczta.onet.pl) wrote: Hello. I have discovered how to add resource limits for the user, like how much memory the user can use, or how much cpu time. Here is the problem: /tmp seems a way for the user to circumvent this restriction. Is there a way to protect it too? Nope. There have been discussions for adding quota to tmpfs, but this lead nowhere. You can disable tmpfs-on-/tmp, and run it on xfs or ext4 instead and use classic per-user quota though. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] users and per user limits (tmpfs)
Hi, 2015-04-28 11:39 GMT+02:00 Lennart Poettering mzerq...@0pointer.de: On Tue, 28.04.15 00:55, Michał Zegan (webczat_...@poczta.onet.pl) wrote: Hello. I have discovered how to add resource limits for the user, like how much memory the user can use, or how much cpu time. Here is the problem: /tmp seems a way for the user to circumvent this restriction. Is there a way to protect it too? Nope. There have been discussions for adding quota to tmpfs, but this lead nowhere. https://bugzilla.redhat.com/show_bug.cgi?id=693253 You can disable tmpfs-on-/tmp, and run it on xfs or ext4 instead and use classic per-user quota though. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Best regards, Michal http://eventhorizon.pl/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] users and per user limits (tmpfs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I have discovered how to add resource limits for the user, like how much memory the user can use, or how much cpu time. Here is the problem: /tmp seems a way for the user to circumvent this restriction. Is there a way to protect it too? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVPr5pAAoJEHb1CzgxXKwY+0kP/jTk+wdUPlcjmu8NDhUSBSi4 qluPAbClFUuxQaEgVPPCF6kRR7n4oMJzY4/j1znZfiWkSdJd/vlD/80gxleeHKd3 CchLVqx5x++u308zVI45an9gH9gKrR51tYTCyiwsdJ6IXGGRTza0CmNxtDbzoGO4 cgfs7XMlBjwVJgMRvltLYa+xuMp4pJ65V/lir5LIRgZaTeK9FC4I7C1/+kwKylQq /STs0QIiale8+/1MaAHBdyl8s6Bs1Eovry4DRJ9NN3Ae5S09b4RpurBeGIjV6+DU hl4GVpWFhnAWin1FdOCTzJYBJJ1qiAAeEdZovCtSA6hTfGydgEv0nzqh7oxr3KgM eWDC15XIw3wjGTIEEsRbkMTogmfBXwDd0xD+UJwBpulCtis7j4Y7Pnul1Yi7DtYe yIh4PaLNP1j6bTOTVx9tRSa/MzCv0n6aKCFNmrFpD0wAoN27gmiu2nHh0fhJWnhL WmytvPARV/P/5ZfBnCTqzvq1xXeX4UqCcGoZ30GPyaGiQPZ5qleHzwAuWQ7taxgL /6cJOVv/klQlbrgnm8Fc1DsHzUBRZpns10aUX361iv6fxZKZHn1oNCDB442utJ/f Vix++eCZy68kFkdj/8X+DSu3GgBKCSGRoKMKNSO9iMyGm/iHKf5pTfLdGZhUk+TS xw4MZaPTzcJTaOBf021W =/7yf -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
