> This also means that a kuid outside of the range 10-165535
> is literally meaningless with respect to that mount - the kernel
> has no way to map it to an id valid in the filesystem.
> That is the real reason for the patch.
That is a compelling point. mounts inside a user-namespace are onl
On Thu, Sep 01, 2016 at 03:11:30PM -, oleg wrote:
> Question (related to UBUNTU: SAUCE: fs: Refuse uid/gid changes which don't
> map into s_user_ns)
> ---
>
> When an overlayfs is mounted inside a user-namespace, should it permit
> the creation of inodes in the upper l
Question (related to UBUNTU: SAUCE: fs: Refuse uid/gid changes which don't map
into s_user_ns)
---
When an overlayfs is mounted inside a user-namespace, should it permit
the creation of inodes in the upper layer with uids that are outside the
user-namespace?
My Tentative
> First, starting in xenial the tmpfs mount isn't going to allow any
inodes to be created in it that > are not mapped into the user
namespace.
Is this specific to tmpfs? I was unable to locate the relevant
code/commit.
--
You received this bug notification because you are a member of Ubuntu
Bug
Real-world-use case: running ephemeral, containerized instances of an
app:
There may be multiple instances of the app, each running
in a separate ephemeral container with a unique uid_map.
The app's configuration directory is permanently stored on the host,
and is mounted in each container using
I had a slight misunderstanding when I looked at the code previously.
The copy up is of the parent directory, which makes sense because it
needs to modify one of the dirents in that directory. Which by extension
means that every ancestor of the dirent being unlinked needs to be
copied up.
So the p
On Mon, Aug 29, 2016 at 06:26:54PM -, oleg wrote:
> Naive question regarding copy-up: Do the files in the upperdir and
> lowerdir need to have the same owner? If not, could copy-up be amended
> so that it behaves similarly to the copying of a root-owned file by a
> non-root user? Ie the owne
Thank you for the detailed explanation.
Since the underlying problem is that overlayfs is not (yet very)
namespace aware, this issue may be intractable.
Naive question regarding copy-up: Do the files in the upperdir and
lowerdir need to have the same owner? If not, could copy-up be amended
so t
I'm pretty sure this is related to copy up. For some reason, when
unlinking a file in the lowerdir that isn't in the upperdir overlayfs
first copies up the file from the lowerdir, then replaces it with a
whiteout. There are a couple of problems with letting the user create
the inode in the upperdir
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Tags added: kernel-dakye
** Tags removed: kernel-dakye
** Tags added: kernel-da-key
** Changed in: linux (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bug
** Tags added: bisect-done kernel-bug
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1617388
Title:
When using overlayfs with kernel 4.4, some files cannot be deleted.
To manage notifications about
For reference, here is the bad commit:
commit eac15dc
Author: Seth Forshee
Date: Wed Nov 19 11:00:56 2014 -0600
UBUNTU: SAUCE: fs: Refuse uid/gid changes which don't map into s_user_ns
Add checks to inode_change_ok to verify that uid and gid changes
will map into the superbloc
git bisect of the ubuntu-xenial tree:
last good commit: 0e9c9b5 UBUNTU: SAUCE: cred: Reject inodes with invalid ids
in set_create_file_as()
first bad commit: eac15dc UBUNTU: SAUCE: fs: Refuse uid/gid changes which don't
map into s_user_ns
--
You received this bug notification because you are a
** Description changed:
#!/bin/bash
# -
# This script exhibits a bug in overlayfs in kernel 4.4.
# The bug is not present in kernel 4.2.
# The bug can be reproduced in an x86_64 virtual-machine;
# 32-bit has not been t
More Apport-Collect data:
AlsaDevices:
total 0
crw-rw 1 root audio 116, 1 Aug 26 15:09 seq
crw-rw 1 root audio 116, 33 Aug 26 15:09 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.14.1-0ubuntu3.21
Architecture: amd64
ArecordDevices: Error: [Errno 2] No su
apport information
** Tags added: apport-collected trusty uec-images
** Description changed:
#!/bin/bash
# -
# This script exhibits a bug in overlayfs in kernel 4.4.
# The bug is not present in kernel 4.2.
# The bug ca
16 matches
Mail list logo