Re: strace of io_uring events?

On Tue, Jul 21, 2020, at 11:58 AM, Stefano Garzarella wrote: > my use case concerns virtualization. The idea, that I described in the > proposal of io-uring restrictions [1], is to share io_uring CQ and SQ queues > with a guest VM for block operations. Virtualization being a strong security

Re: kernel BUG at mm/hugetlb.c:LINE!

On Tue, May 12, 2020, at 11:04 AM, Miklos Szeredi wrote: > > However, in this syzbot test case the 'file' is in an overlayfs filesystem > > created as follows: > > > > mkdir("./file0", 000) = 0 > > mount(NULL, "./file0", "hugetlbfs", MS_MANDLOCK|MS_POSIXACL, NULL) = 0 > >

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

On Thu, Jan 18, 2018, at 11:44 AM, Jeff Moyer wrote: > Jeff Moyer writes: > > > FYI, this kernel has issues. It will boot up, but I don't have > > networking, and even rebooting doesn't succeed. I'm looking into it. > > A bisect lands on: eventfd: switch to ->poll_mask.

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

On Thu, Jan 18, 2018, at 11:44 AM, Jeff Moyer wrote: > Jeff Moyer writes: > > > FYI, this kernel has issues. It will boot up, but I don't have > > networking, and even rebooting doesn't succeed. I'm looking into it. > > A bisect lands on: eventfd: switch to ->poll_mask. That's not super >

Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

On Wed, Nov 1, 2017, at 03:02 PM, Shawn Landden wrote: > > This solves the fact that epoll_pwait() already is a 6 argument (maximum > allowed) syscall. But what if the process has multiple epoll() instances in > multiple threads? Well, that's a subset of the general question of - what is the

Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

On Wed, Nov 1, 2017, at 03:02 PM, Shawn Landden wrote: > > This solves the fact that epoll_pwait() already is a 6 argument (maximum > allowed) syscall. But what if the process has multiple epoll() instances in > multiple threads? Well, that's a subset of the general question of - what is the

Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

On Wed, Nov 1, 2017, at 11:16 AM, Colin Walters wrote: > > as the maintainer of glib2 which is used by a *lot* of things; I'm not (I meant to say "a" maintainer) Also, while I'm not an expert in Android, I think the "what to kill" logic there lives in userspace, ri

Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

On Wed, Nov 1, 2017, at 11:16 AM, Colin Walters wrote: > > as the maintainer of glib2 which is used by a *lot* of things; I'm not (I meant to say "a" maintainer) Also, while I'm not an expert in Android, I think the "what to kill" logic there lives in userspace, ri

Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

On Wed, Nov 1, 2017, at 01:32 AM, Shawn Landden wrote: > It is common for services to be stateless around their main event loop. > If a process passes the EPOLL_KILLME flag to epoll_wait5() then it > signals to the kernel that epoll_wait5() may not complete, and the kernel > may send SIGKILL if

Re: [RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

On Wed, Nov 1, 2017, at 01:32 AM, Shawn Landden wrote: > It is common for services to be stateless around their main event loop. > If a process passes the EPOLL_KILLME flag to epoll_wait5() then it > signals to the kernel that epoll_wait5() may not complete, and the kernel > may send SIGKILL if

Re: [PATCH 1/3] autofs - fix AT_NO_AUTOMOUNT not being honored

On Tue, Aug 8, 2017, at 12:26 AM, Ian Kent wrote: > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -3022,8 +3022,7 @@ static inline int vfs_lstat(const char __user *name, > struct kstat *stat) > static inline int vfs_fstatat(int dfd, const char __user *filename, >

Re: [PATCH 1/3] autofs - fix AT_NO_AUTOMOUNT not being honored

On Tue, Aug 8, 2017, at 12:26 AM, Ian Kent wrote: > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -3022,8 +3022,7 @@ static inline int vfs_lstat(const char __user *name, > struct kstat *stat) > static inline int vfs_fstatat(int dfd, const char __user *filename, >

Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Mon, Jul 31, 2017, at 02:23 PM, Darrick J. Wong wrote: > I don't think F_SEAL_{SHRINK,GROW} prevents reflinking or CoW of file data, > which are two things that cannot happen under S_IOMAP_IMMUTABLE that > aren't size changes. From the implementation it looks like shrink and > grow are only

Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Mon, Jul 31, 2017, at 02:23 PM, Darrick J. Wong wrote: > I don't think F_SEAL_{SHRINK,GROW} prevents reflinking or CoW of file data, > which are two things that cannot happen under S_IOMAP_IMMUTABLE that > aren't size changes. From the implementation it looks like shrink and > grow are only

Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Mon, Jul 31, 2017, at 12:32 PM, Colin Walters wrote: > On Mon, Jul 31, 2017, at 12:29 PM, Dan Williams wrote: > > > > How is S_CONTENTS_IMMUTABLE different than S_IMMUTABLE? > > We still want the ability to make hardlinks. Also of course, symmetrically, to unlink. I

Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Mon, Jul 31, 2017, at 12:32 PM, Colin Walters wrote: > On Mon, Jul 31, 2017, at 12:29 PM, Dan Williams wrote: > > > > How is S_CONTENTS_IMMUTABLE different than S_IMMUTABLE? > > We still want the ability to make hardlinks. Also of course, symmetrically, to unlink. I

Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Mon, Jul 31, 2017, at 12:29 PM, Dan Williams wrote: > > How is S_CONTENTS_IMMUTABLE different than S_IMMUTABLE? We still want the ability to make hardlinks.

Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Mon, Jul 31, 2017, at 12:29 PM, Dan Williams wrote: > > How is S_CONTENTS_IMMUTABLE different than S_IMMUTABLE? We still want the ability to make hardlinks.

Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Sat, Jul 29, 2017, at 03:43 PM, Dan Williams wrote: > An inode with this flag set indicates that the file's block map cannot > be changed, no size change, deletion, hole-punch, range collapse, or > reflink. > > The implementation of toggling the flag and sealing the state of the > extent map

Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Sat, Jul 29, 2017, at 03:43 PM, Dan Williams wrote: > An inode with this flag set indicates that the file's block map cannot > be changed, no size change, deletion, hole-punch, range collapse, or > reflink. > > The implementation of toggling the flag and sealing the state of the > extent map

Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls

On Wed, May 31, 2017, at 10:47 AM, David Howells wrote: > > So if the mount-in-container is mostly init containers, and for init > > containers you have *all* namespaces usually, does it make > > sense to have the capability to match namespaces for key services? > > Yes. > > If I don't provide

Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls

On Wed, May 31, 2017, at 10:47 AM, David Howells wrote: > > So if the mount-in-container is mostly init containers, and for init > > containers you have *all* namespaces usually, does it make > > sense to have the capability to match namespaces for key services? > > Yes. > > If I don't provide

Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls

On Tue, May 30, 2017, at 12:08 PM, David Howells wrote: > > KEY_SERVICE_NS_UTS > KEY_SERVICE_NS_IPC > KEY_SERVICE_NS_MNT > KEY_SERVICE_NS_PID > KEY_SERVICE_NS_NET > KEY_SERVICE_NS_CGROUP Any reasons not to reuse the CLONE_ flags? > which select those

Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls

On Tue, May 30, 2017, at 12:08 PM, David Howells wrote: > > KEY_SERVICE_NS_UTS > KEY_SERVICE_NS_IPC > KEY_SERVICE_NS_MNT > KEY_SERVICE_NS_PID > KEY_SERVICE_NS_NET > KEY_SERVICE_NS_CGROUP Any reasons not to reuse the CLONE_ flags? > which select those

Re: [RFC][PATCH 0/9] Make containers kernel objects

On Tue, May 23, 2017, at 11:31 AM, Jeff Layton wrote: > > nfsdcltrack was originally nfsdcld, a long running daemon that used > rpc_pipefs to talk to the kernel. That meant that you had to make sure > it gets enabled by systemd (or sysvinit, etc). If it dies, then you also > want to ensure that

Re: [RFC][PATCH 0/9] Make containers kernel objects

On Tue, May 23, 2017, at 11:31 AM, Jeff Layton wrote: > > nfsdcltrack was originally nfsdcld, a long running daemon that used > rpc_pipefs to talk to the kernel. That meant that you had to make sure > it gets enabled by systemd (or sysvinit, etc). If it dies, then you also > want to ensure that

Re: [RFC][PATCH 0/9] Make containers kernel objects

On Tue, May 23, 2017, at 10:30 AM, Djalal Harouni wrote: > > Maybe it depends on the cases, a general approach can be too difficult > to handle especially from the security point. Maybe it is better to > identify what operations need what context, and a userspace > service/proxy can act using

Re: [RFC][PATCH 0/9] Make containers kernel objects

On Tue, May 23, 2017, at 10:30 AM, Djalal Harouni wrote: > > Maybe it depends on the cases, a general approach can be too difficult > to handle especially from the security point. Maybe it is better to > identify what operations need what context, and a userspace > service/proxy can act using

Re: [PATCH 3/3] autofs - fix AT_NO_AUTOMOUNT not being honored

On Wed, May 10, 2017, at 12:18 AM, Ian Kent wrote: > The fstatat(2) and statx() calls can pass the flag AT_NO_AUTOMOUNT > which is meant to clear the LOOKUP_AUTOMOUNT flag and prevent triggering > of an automount by the call. But this flag is unconditionally cleared > for all stat family system

Re: [PATCH 3/3] autofs - fix AT_NO_AUTOMOUNT not being honored

On Wed, May 10, 2017, at 12:18 AM, Ian Kent wrote: > The fstatat(2) and statx() calls can pass the flag AT_NO_AUTOMOUNT > which is meant to clear the LOOKUP_AUTOMOUNT flag and prevent triggering > of an automount by the call. But this flag is unconditionally cleared > for all stat family system

Re: [PATCH 1/2] vfs: implement fchmodat2() syscall

On Tue, Apr 11, 2017, at 02:07 PM, Eric Blake wrote: > > A good idea on the surface. But reading the man page of openat(), the > section on O_PATH says: >The file > itself is not opened, and other file operations (e.g., > read(2), > write(2), fchmod(2),

Re: [PATCH 1/2] vfs: implement fchmodat2() syscall

On Tue, Apr 11, 2017, at 02:07 PM, Eric Blake wrote: > > A good idea on the surface. But reading the man page of openat(), the > section on O_PATH says: >The file > itself is not opened, and other file operations (e.g., > read(2), > write(2), fchmod(2),

Re: [PATCH 1/2] vfs: implement fchmodat2() syscall

On Tue, Feb 28, 2017, at 02:23 PM, Eric Blake wrote: > Might also be worth mentioning that this patch is required in order to > solve CVE-2016-9602, per discussion at > https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg06089.html I only briefly looked at this, but can't `open(...,

Re: [PATCH 1/2] vfs: implement fchmodat2() syscall

On Tue, Feb 28, 2017, at 02:23 PM, Eric Blake wrote: > Might also be worth mentioning that this patch is required in order to > solve CVE-2016-9602, per discussion at > https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg06089.html I only briefly looked at this, but can't `open(...,

Re: [RFC] [PATCH] Add a "nolinks" mount option.

On Wed, Oct 19, 2016, at 07:28 AM, Mattias Nissler wrote: > > Note that O_NOFOLLOW only affects the final path component. If there's > a symlink in any of the parent directories, that'll still be traversed > even with O_NOFOLLOW. This situation is less risky as an attacker will > have to deal

Re: [RFC] [PATCH] Add a "nolinks" mount option.

On Wed, Oct 19, 2016, at 07:28 AM, Mattias Nissler wrote: > > Note that O_NOFOLLOW only affects the final path component. If there's > a symlink in any of the parent directories, that'll still be traversed > even with O_NOFOLLOW. This situation is less risky as an attacker will > have to deal

Re: [RFC] [PATCH] Add a "nolinks" mount option.

On Mon, Oct 17, 2016, at 09:02 AM, Mattias Nissler wrote: > OK, no more feedback thus far. Is there generally any interest in a > mount option to avoid path name aliasing resulting in target file > confusion? Perhaps a version that only disables symlinks instead of > also hard-disabling files

Re: [RFC] [PATCH] Add a "nolinks" mount option.

On Mon, Oct 17, 2016, at 09:02 AM, Mattias Nissler wrote: > OK, no more feedback thus far. Is there generally any interest in a > mount option to avoid path name aliasing resulting in target file > confusion? Perhaps a version that only disables symlinks instead of > also hard-disabling files

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

On Thu, Jul 21, 2016, at 12:39 PM, Eric W. Biederman wrote: > > This patchset addresses two use cases: > - Implement a sane upper bound on the number of namespaces. > - Provide a way for sandboxes to limit the attack surface from > namespaces. Perhaps this is obvious, but since you didn't

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

On Thu, Jul 21, 2016, at 12:39 PM, Eric W. Biederman wrote: > > This patchset addresses two use cases: > - Implement a sane upper bound on the number of namespaces. > - Provide a way for sandboxes to limit the attack surface from > namespaces. Perhaps this is obvious, but since you didn't

Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote: > It's not possible to read the process umask without also modifying it, > which is what umask(2) does. A library cannot read umask safely, > especially if the main program might be multithreaded. I assume you just want to do this

Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote: > It's not possible to read the process umask without also modifying it, > which is what umask(2) does. A library cannot read umask safely, > especially if the main program might be multithreaded. I assume you just want to do this

Re: Thoughts on tightening up user namespace creation

On Wed, Mar 9, 2016, at 01:14 PM, Kees Cook wrote: > On Mon, Mar 7, 2016 at 9:15 PM, Andy Lutomirski wrote: > > Hi all- > > > > There are several users and distros that are nervous about user > > namespaces from an attack surface point of view. > > > > - RHEL and Arch have

Re: Thoughts on tightening up user namespace creation

On Wed, Mar 9, 2016, at 01:14 PM, Kees Cook wrote: > On Mon, Mar 7, 2016 at 9:15 PM, Andy Lutomirski wrote: > > Hi all- > > > > There are several users and distros that are nervous about user > > namespaces from an attack surface point of view. > > > > - RHEL and Arch have userns disabled. > > >

Re: [PATCH v3 0/7] User namespace mount updates

On Thu, Nov 19, 2015, at 02:53 AM, Richard Weinberger wrote: > Erm, I don't want this in the kernel. That's why I've proposed the lklfuse > approach. I already said this before but just to repeat, since I'm confused: How would "lklfuse" be different from http://libguestfs.org/ which we at Red

Re: [PATCH v3 0/7] User namespace mount updates

On Thu, Nov 19, 2015, at 02:53 AM, Richard Weinberger wrote: > Erm, I don't want this in the kernel. That's why I've proposed the lklfuse > approach. I already said this before but just to repeat, since I'm confused: How would "lklfuse" be different from http://libguestfs.org/ which we at Red

Re: [PATCH 0/7] Initial support for user namespace owned mounts

It's worth noting here that I think a lot of the use cases for unprivileged mounts are testing/development type things, and these are pretty well covered by: http://libguestfs.org/ Basically it just runs the host kernel in a VM, and the userspace is a minimal agent that you can talk to over

Re: [PATCH 0/7] Initial support for user namespace owned mounts

It's worth noting here that I think a lot of the use cases for unprivileged mounts are testing/development type things, and these are pretty well covered by: http://libguestfs.org/ Basically it just runs the host kernel in a VM, and the userspace is a minimal agent that you can talk to over

Re: [PATCH 0/7] Initial support for user namespace owned mounts

On Thu, Jul 16, 2015, at 12:47 AM, Eric W. Biederman wrote: > With that said desktop environments have for a long time been > automatically mounting whichever filesystem you place in your computer, > so in practice what this is really about is trying to align the kernel > with how people use

Re: [PATCH 0/7] Initial support for user namespace owned mounts

On Thu, Jul 16, 2015, at 12:47 AM, Eric W. Biederman wrote: With that said desktop environments have for a long time been automatically mounting whichever filesystem you place in your computer, so in practice what this is really about is trying to align the kernel with how people use

Re: [PATCH] overlayfs: Warn on copy up if a process has a R/O fd open to the lower file

On Thu, May 28, 2015, at 02:46 PM, David Howells wrote: > Print a warning when overlayfs copies up a file if the process that triggered > the copy up has a R/O fd open to the lower file being copied up. Why not an option to make it an error? If one's goal is to use overlayfs without apps

Re: [PATCH] overlayfs: Warn on copy up if a process has a R/O fd open to the lower file

On Thu, May 28, 2015, at 02:46 PM, David Howells wrote: Print a warning when overlayfs copies up a file if the process that triggered the copy up has a R/O fd open to the lower file being copied up. Why not an option to make it an error? If one's goal is to use overlayfs without apps

Re: [PATCH 0/6] File Sealing & memfd_create()

On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski wrote: COW links can do this already, I think. Of course, you'll have to use a filesystem that supports them. COW is nice if the filesystem supports them, but my userspace code needs to be filesystem agnostic. Because of that, the design

Re: [PATCH 0/6] File Sealing & memfd_create()

On Thu, Mar 20, 2014 at 11:32 AM, ty...@mit.edu wrote: Looking at your patches, and what files you are modifying, you are enforcing this in the low-level file system. I would love for this to be implemented in the filesystem level as well. Something like the ext4 immutable bit, but with the

Re: [PATCH 0/6] File Sealing memfd_create()

On Thu, Mar 20, 2014 at 11:32 AM, ty...@mit.edu wrote: Looking at your patches, and what files you are modifying, you are enforcing this in the low-level file system. I would love for this to be implemented in the filesystem level as well. Something like the ext4 immutable bit, but with the

Re: [PATCH 0/6] File Sealing memfd_create()

On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski l...@amacapital.net wrote: COW links can do this already, I think. Of course, you'll have to use a filesystem that supports them. COW is nice if the filesystem supports them, but my userspace code needs to be filesystem agnostic. Because

Need for llistxattrat()/lgetxattrat()/lsetxattrat()

Hi, So at the moment the kernel has pretty comprehensive support for the *at() variants of file API calls, and at one point I was rewriting my app to be a modern Unix citizen and use the *at variants, but I ran into one admittedly obscure corner case, which is the lack of API calls to manipulate

Need for llistxattrat()/lgetxattrat()/lsetxattrat()

Hi, So at the moment the kernel has pretty comprehensive support for the *at() variants of file API calls, and at one point I was rewriting my app to be a modern Unix citizen and use the *at variants, but I ran into one admittedly obscure corner case, which is the lack of API calls to manipulate

Re: [RFC] teach argv_split() to ignore the spaces surrounded by \e

On Mon, 2013-05-13 at 16:35 +0200, Oleg Nesterov wrote: > Yes, we can change format_corename() to construct "argv" by hand, and > this was my iniital plan. But perhaps it would be better to not uglify > this code even more? Sure this \e is less code, but it seems pretty ugly to me. Maybe a way

Re: [RFC] teach argv_split() to ignore the spaces surrounded by \e

On Mon, 2013-05-13 at 16:35 +0200, Oleg Nesterov wrote: Yes, we can change format_corename() to construct argv by hand, and this was my iniital plan. But perhaps it would be better to not uglify this code even more? Sure this \e is less code, but it seems pretty ugly to me. Maybe a way to

Re: [systemd-devel] [PATCH 2/2] coredump: Handle programs with spaces in COMM

On Fri, 2013-05-03 at 17:08 +0200, Lennart Poettering wrote: > It sounds really wrong to first merge this into one string and then > split it up again. It sounds much more sensible to instead just pass the > string array around all the time. What's the reason to make this one > string first? I'm

Re: [systemd-devel] [PATCH 2/2] coredump: Handle programs with spaces in COMM

On Fri, 2013-05-03 at 17:08 +0200, Lennart Poettering wrote: It sounds really wrong to first merge this into one string and then split it up again. It sounds much more sensible to instead just pass the string array around all the time. What's the reason to make this one string first? I'm

linux-user-chroot 2012.2

chroot(2), create Linux bind mounts, and use some Linux container features. It's primarily intended for use by build systems. Project information --- There's no web page yet; send patches to Colin Walters -- To unsubscribe from this list: send the line "unsubscribe

linux-user-chroot 2012.2

chroot(2), create Linux bind mounts, and use some Linux container features. It's primarily intended for use by build systems. Project information --- There's no web page yet; send patches to Colin Walters walt...@verbum.org -- To unsubscribe from this list: send the line