[Bug 1010713] create and own %{_datadir}/gocode and %{_datadir}/gocode/src
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1010713
Fedora Update System <updates(a)fedoraproject.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ON_QA |CLOSED
Fixed In Version| |golang-1.2.2-2.fc20
Resolution|--- |ERRATA
Last Closed| |2014-05-20 22:36:44
--- Comment #12 from Fedora Update System <updates(a)fedoraproject.org> ---
golang-1.2.2-2.fc20 has been pushed to the Fedora 20 stable repository. If
problems still persist, please make note of it in this bug report.
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years
[Bug 1098719] New: SE permission problems with volume mounting
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1098719
Bug ID: 1098719
Summary: SE permission problems with volume mounting
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: mads(a)kiilerich.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
[mk@xps x]$ getenforce
Enforcing
with docker-io-0.11.1-1.fc20.x86_64 :
[mk@xps x]$ docker run --rm -v $PWD:/test hg-dockerrpm-fedora ls -l /test
(as expected)
with docker-io-0.11.1-3.fc20.x86_64 :
[mk@xps x]$ docker run --rm -v $PWD:/test hg-dockerrpm-fedora ls -l /test
ls: cannot open directory /test: Permission denied
- but after setenforce 0 it works anyway.
I also see https://bugzilla.redhat.com/show_bug.cgi?id=1096375 - they might be
related or have the same root cause.
Workaround: stick to 0.11.1-1
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years
[Bug 1094198] New: docker-io-0.10 access to /sys
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1094198
Bug ID: 1094198
Summary: docker-io-0.10 access to /sys
Product: Fedora
Version: 20
Component: docker-io
Severity: urgent
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
This bugzilla maps the https://bugzilla.redhat.com/show_bug.cgi?id=1094188
issue on newer docker-io-0.10 on real hardware.
Docker gives access to host /sys. This is expected as some apps requires /sys
and one would expect it's protected (in --privileged=False). Well, is it?
This time I tried `echo mem > /sys/power/state` which (unlike on older docker)
succeeded and suspended the whole laptop. I guess this is not required from
containerized machine to be able to do?
Additionally I tried modifying the cpu frequence:
echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
passes (which is IMO improper behavior)
Last but not least I tried `poweroff -f`, but "sadly" it just stopped the
container without powering off the host machine.
Version-Release number of selected component (if applicable):
docker-io-0.10.0-2.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Play with /sys
Actual results:
container is able to interact/suspend/modify the underlying host machine.
Expected results:
docker should prevent these operations.
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years
[Bug 1094188] New: Docker access to /sys
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1094188
Bug ID: 1094188
Summary: Docker access to /sys
Product: Fedora
Version: 19
Component: docker-io
Severity: urgent
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
Docker gives access to host /sys. This is expected as some apps requires /sys
and one would expect it's protected (in --privileged=False). Well, is it?
After first round directly on HW (resulting in crashed X and lost of all work)
I switched to qemu vm:
My first game was echo disk > /sys/power/state. It fails with:
sh: write error: Operation not permitted
Than I tried the same in while loop:
...
PM: Cannot find swap device, try swapon -a
PM: Cannot get swap writer
PM: Cannot find swap device, try swapon -a
PM: Cannot get swap writer
PM: Cannot find swap device, try swapon -a
PM: Cannot get swap writer
...
Which significantly slowed the VM response. When I tried the same and connect
using ssh, it was almost unusable and after couple of seconds hanged the whole
VM (ctrl+alt+delete not working)
Version-Release number of selected component (if applicable):
qemu machine running F19:
docker-io-0.9.1-1.fc19.x86_64
kernel-3.12.8-200
How reproducible:
Always
Steps to Reproduce:
1. Just play with /sys
Actual results:
Most stuff works even in non-privileged mode
Expected results:
Docker should prevent hazardous interaction with the machine (suspend, cpu
settings, ...)
Additional info:
The docker-io-0.10 behaves even weirder, I'll fill separate bugzilla for it.
--
You are receiving this mail because:
You are on the CC list for the bug.
10 years