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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https
** 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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Title:
ove
** 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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.laun
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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/
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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/
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 inst
** Also affects: linux-lts-wily (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Title:
overlay: mkdir fails if directory exist
** 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 Kernel
Packages, which is subscribed to linux in
** Tags removed: kernel-key
** Tags added: kernel-da-key
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Title:
overlay: mkdir fails if directory exists in lowerdir in a user
na
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
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 sai
> 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 t
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 remo
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
ro
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 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, on
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 apply
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 l
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 check
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
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 notif
#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 Kernel
Packages, which is subscribed to linux in Ubuntu.
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 tha
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.
--
You
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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1531747
Title:
overlay: mkdir fails if directory exists
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.
--
You
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)
I
29 matches
Mail list logo
