This bug was fixed in the package linux - 4.4.0-8.23
---
linux (4.4.0-8.23) xenial; urgency=low
* cgroup namespace mounts broken in containers (LP: #1549398)
- SAUCE: kernfs: Always set super block owner to init_user_ns
* 4.4.0-7.22 no longer boots on arm64 (LP: #1547718)
** Branch linked: lp:~ubuntu-branches/ubuntu/trusty/linux-lts-wily
/trusty-security
** Branch linked: lp:~ubuntu-branches/ubuntu/trusty/linux-lts-wily
/trusty-proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Branch linked: lp:ubuntu/trusty-security/linux-lts-vivid
** Branch linked: lp:ubuntu/trusty-proposed/linux-lts-vivid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Title:
overlay: mkdir
** Changed in: linux-lts-wily (Ubuntu Wily)
Importance: Undecided => High
** Changed in: linux-lts-wily (Ubuntu Xenial)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux-lts-wily (Ubuntu Wily)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux-lts-wily (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1531747
This bug was fixed in the package linux - 4.2.0-30.35
---
linux (4.2.0-30.35) wily; urgency=low
[ Seth Forshee ]
* SAUCE: cred: Add clone_cred() interface
- LP: #1531747, #1534961, #1535150
- CVE-2016-1575 CVE-2016-1576
* SAUCE: overlayfs: Use mounter's credentials
** Also affects: linux-lts-wily (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Title:
overlay: mkdir fails if directory exists in
** Changed in: linux (Ubuntu Wily)
Assignee: (unassigned) => Seth Forshee (sforshee)
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Seth Forshee (sforshee)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags removed: kernel-key
** Tags added: kernel-da-key
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Title:
overlay: mkdir fails if directory exists in lowerdir in a user
namespace
To
FWIW, bug #1480411, "rm -r * fails to delete directories when using
overlayfs in a user-namespace", might be a duplicate of this bug. In
both bugs the script works on the host but fails in a user-namespace
with error EPERM. In this bug the operation which triggers the error is
'mkdir', while in
> Something I'm still not sure about is what would happen if you made a
> symlink, bind mount, etc. in upperdir with the same name as an unrelated
> file in lowerdir. This is worth checking out.
just tried a symlink and it didn't seem to affect the host directory
(/opt/cisco) which was symlinked
ovl_rename2 seems okay. As before, the vfs does inode permission checks
on the overlayfs inodes which results in checks on the upper and/or
lower dir inodes as appropriate. These checks appear to be sufficient to
imply permission to do everything ovl_rename2 does with elevated
credentials. That
On Thu, Jan 14, 2016 at 12:17:06AM -, Serge Hallyn wrote:
> Does it require the workdir to be empty?
Not empty. It wants to remove workdir/work if it exists and then create
workdir/work, see ovl_workdir_create. Removing workdir/work is done as
the user which is mounting, so nothing can be
Does it require the workdir to be empty?
I.e. is there a way (symlink, bind mount, something else) that a user
could use a dir they own which has a child which they don't own?
It looks like no, since
root@w1:/tmp# mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=workdir
overlay /mnt
On Tue, Jan 12, 2016 at 05:16:28PM -, Serge Hallyn wrote:
> I'm still looking, but it may be safe to say that all needed inode
> checks are already done before we call ovl_set_opaque() so that we
> can indeed just use prepare_kernel_cred(NULL) instead of prepare_cred().
I've been looking too,
On Tue, Jan 12, 2016 at 04:56:24PM -, Serge Hallyn wrote:
> Quoting Seth Forshee (seth.forshee...@canonical.com):
> > I don't know why #2 is that much grosser than what's there now. It's
>
> I didn't mean gross as in eeuw, I meant not fine-grained enough.
>
> Because the capability will
On Tue, Jan 12, 2016 at 05:16:28PM -, Serge Hallyn wrote:
> in ovl_clear_empty(), the opaque bit is set on the dir in workingdir
>
> in ovl_create_over_whiteout() (the case we're currently looking at) it is
> also being set in the working dir.
>
> in ovl_rename2(), it is set in two places,
I don't know why #2 is that much grosser than what's there now. It's
already only taking the cap for setting the xattr, and taking
CAP_SYS_ADMIN in init_user_ns seems to be what it's really wanting to do
there. The difference now though is that before that capability would
have been required to do
Quoting Seth Forshee (seth.forshee...@canonical.com):
> I don't know why #2 is that much grosser than what's there now. It's
I didn't mean gross as in eeuw, I meant not fine-grained enough.
Because the capability will apply to inode permissions checks,
and we only want it to be used for the
in ovl_clear_empty(), the opaque bit is set on the dir in workingdir
in ovl_create_over_whiteout() (the case we're currently looking at) it is
also being set in the working dir.
in ovl_rename2(), it is set in two places, on the upper dentries for
both the old and new.
So it is never set on the
#2 is probably a bit too gross - we really only need the cap for the setting
of the OVL_XATTR_OPAQUE xattr in ovl_set_opaque. So we could simply override
creds again there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
hat may not be ok for the ovl_rename2 case.
What we want is for inode permissions to be checked, but only the
bit in xattr_permission() checking for trusted.* to accept ns_capable.
We could special-case that in xattr_permission(), but that's not
particularly nice.
--
You received this bug
Hmm. In this case it's really the kernel that is writing the xattr, so
in that case #2 kind of makes sense. It's also more than a bit scary,
assigning CAP_SYS_ADMIN in init_user_ns to a task from a user namespace.
Now we're already doing it for unprivileged users in init_user_ns which
isn't all
Ok, I see. At one point we had a special case to allow the overlay code
to write trusted.* xattrs for creating whiteouts.
However that is gone. Therefore when overlayfs v1 (mount -t overlayfs)
is mounted, root in a user namespace also is not able to rm a file which
exists in the lower fs.
Some
The type of the underlaying file does not matter, only the type of the
replacing object.
So if you
touch $t/dev; rm $t/dev; touch $t/dev
mkdir $t/dev; rmdir $t/ev; touch $t/dev
those succeed, while
touch $t/dev; rm $t/dev; mkdir $t/dev
mkdir $t/dev; rm $t/dev; mkdir $t/dev
both fail.
--
In ovl_create_over_whiteout(), the ovl_set_opaque() in the S_ISDIR()
block failed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Title:
overlay: mkdir fails if directory exists in lowerdir
summary overlay: mkdir in user namespace fails if directory exists in
lowerdir"
** Description changed:
If a directory exists in the lowerdir but not in the mounted
overlay, then mkdir of the directory in the target dir results
in a mysterious -EPERM. I've seen this both in wily kernel
Quoting Joseph Salisbury (joseph.salisb...@canonical.com):
> Can you see if this bug also happens with the latest mainline kernel? It can
> be downloaded from:
That is not an option, because the mainline kernel doesn't support unprivileged
overlayfs mounting which is where this happens.
--
Can you see if this bug also happens with the latest mainline kernel? It can
be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc8-wily
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Tags added: kernel-key wily xenial
** Changed in: linux (Ubuntu)
30 matches
Mail list logo