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 t
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
t
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
) users to call 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 th
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 quite
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 r
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 use
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 i
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 cal
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
> h
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 potentia
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
> > chdi
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
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
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 virti
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 H
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 files
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.
> >
>
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 from
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 barri
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(..., O_PATH
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), fchown(2),
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 namespaces
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
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 kthre
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 it
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 is
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.
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
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 su
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,
>
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 hard-
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 with
33 matches
Mail list logo
