I've discovered that a chroot can be escaped by chrooting to any file.
I'm interested on how this plays on attempting to protect /dev/log?
From what I can gather is that chroots should not be used as a security
measure(as they are in this case), but only as a device to run multiple
distributions
Public bug reported:
root@ubuntu:~# ls /run
ls: cannot access /run: Too many levels of symbolic links
root@ubuntu:~# ls -alrt /run /var/run
lrwxrwxrwx 1 root root 8 Dec 24 14:58 /run - /var/run
lrwxrwxrwx 1 root root 4 Dec 25 14:42 /var/run - /run
ProblemType: Bug
DistroRelease: Ubuntu 12.04
** Also affects: debian-base-files
Importance: Undecided
Status: New
** Also affects: sysvinit
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
root@ubuntu:~# dpkg -S /var/run
base-files, initscripts: /run
base-files, dnsmasq-base: /var/run
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/908614
Title:
/run: Too many levels
I made both into a directory with no symlinks. For the time being
/var/run is a link to /run, should be ../run if any thing.
I believe that if /var/run is needed prior to /var being mounted that
/tmp should be used. After var is mounted /tmp can hold symlinks into
/var/run.
--
You received
This was all done using apt-get. After do-release-upgrade had failed to
find an upgrade path, I ran `find /etc/apt -type f -exec sed -i -e
's/lucid/precise/g'` and then I manually went through and downgraded a
few packages to help satisfy dependencies.
I understand that /run is likely needed in
Vary well.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/908614
Title:
/run: Too many levels of symbolic links
To manage notifications about this bug go to:
Public bug reported:
Bug number 1030519 tracks this issue in perl and Bug number 1007089 is
the root cause. In Ubuntu perl is located in /usr/bin/perl, so using
$^X isn't necessarily needed. Also you should investigate using eval()
or other methods to get a sub-perl instance.
One solution may
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to logwatch in Ubuntu.
https://bugs.launchpad.net/bugs/1030520
Title:
logwatch: Makes use of $^X, broken under overlayfs.
To manage notifications about this bug go to:
That's only some what reasonable. One would expect a perl API to work
always(but it doesn't)... However the same is not true of kernel APIs,
the opposite is vary much the case.
You don't call open() and then turn right around and operate on the new
file handle, no you don't even do this usually
There are plenty of other important bugs to work on:
https://bugs.launchpad.net/~cheako
Not everyone who posted on this bug saying it effected them marked it as
having effected them, too sad. The count should be at least 3, but one
wonders how many noobs read the fix and didn't know to at least
Public bug reported:
Package: krb5-user
Version: 1.8.3+dfsg-4
Severity: important
File: /usr/bin/kadmin
Here is a small bit of strace output:
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(775),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
connect(4,
** Bug watch added: Debian Bug tracker #624710
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624710
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/780820
Title:
kadmin: IPv6
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624710
Version 1.9 adds IPv6 support for kadmind and kadmin.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/780820
Title:
kadmin:
Public bug reported:
Binary package hint: qemu-kvm
I'm working on getting a UI to start qemu. In debugging I am working
exclusively on the command line. I'm able to reproduce and correct this
bug from the command line. The UI is libvirt.
The testing I did was to remove part of the command
** Attachment added: BootDmesg.txt
http://launchpadlibrarian.net/49966398/BootDmesg.txt
** Attachment added: CurrentDmesg.txt
http://launchpadlibrarian.net/49966399/CurrentDmesg.txt
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/49966400/Dependencies.txt
**
I wrote a little script that should have solved my problems, however
libvirt has other ideas.
http://pastebin.com/HgwtQ3iL
#!/bin/bash
out_args=( )
while (( $# ))
do if [[ $1 = -drive ]]
then out_args+=( $1 $($2 sed \
-e s/,boot=on//g \
(04:12:14 PM) cheako: operation=exec pid=24359 parent=1
profile=libvirt-02e3d7e8-79e5-6dc3-2954-d43fe1130cdf requested_mask=x::
denied_mask=x:: fsuid=0 ouid=0 name=/usr/bin/qemu-original
(04:12:25 PM) cheako: operation=mknod pid=24361 parent=24360
This bug is about qemu's option, if it's not a bug in qemu then this is
a bug in libvirt for using this option. As for the selinux and apparmor
issues these are bugs in my solution and have nothing to do with the bug
being reported, but instead are related to one of it's /incomplete/
solutions.
That was simple add the following to the apparmor file:
/usr/bin/qemu-original rmix,
/bin/sed rmix,
/tmp/sh-thd-* rw,
Also the dmsg statements that apparmor makes are not recognized by the
SELinux ppl, they should all indicate from whence they hail.
--
qemu -drive boot=on flag causes boot
The BUG here in qemu is that it starts, but then hangs!
** Bug watch added: SourceForge.net Tracker #1977971
http://sourceforge.net/support/tracker.php?aid=1977971
** Also affects: libvirt via
http://sourceforge.net/support/tracker.php?aid=1977971
Importance: Unknown
Status:
After reading the posted email thread, I've come to the conclusion that
the -boot argument is missdocumented/missleading. In actuality it's c
parameter is more like the boot from first or selected hard disk and
d would be boot from first or selected cdrom.
I think it would be best to remove this
I made a change to my script.
#!/bin/bash
out_args=( )
while (( $# ))
do if [[ $1 = -drive ]]
then out_args+=( $1 $($2 sed \
-e s/,boot=on//g \
-e s/boot=on,//g \
-e
Now I see the true bug here. I setup WindowsXP to use the virtio block
driver and now as predicted I can't boot from it. After removing the
wrapper script it seams that GRUB hangs during boot.
Could there be a problem with the int13h driver?
--
qemu -drive boot=on flag causes boot to hang.
After doing some digging I've made the assumption that this is a missing
feature of the BIOS(seabios). I've build the latest code from GIT and
am getting the same result. Using KVM this is working, can that be used
to correct QEMU?
--
qemu -drive boot=on flag causes boot to hang.
Fails to boot is described above, however a recap here would be nice.
The boot process hangs(idle for ever) during the BIOS and/or MBR stage
of the boot.
--
qemu -drive boot=on flag causes boot to hang.
https://bugs.launchpad.net/bugs/591423
You received this bug notification because you are a
ilia,
What SF project, a link would be nice. The current link is kinda fun it
links to that number locally.
--
qemu -drive boot=on flag causes boot to hang.
https://bugs.launchpad.net/bugs/591423
You received this bug notification because you are a member of Ubuntu
Server Team, which is
I have this working at home under KVM, it's the software emulator that
this is broken on.
http://sourceforge.net/tracker/index.php?func=detailaid=1977971group_id=180599atid=893831
This is also something to keep in mind, with or w/o -boot c it's the same.
--
qemu -drive boot=on flag causes boot
Just to be clear the bug was reported while using GRUB, not the Windows
XP loader. Grub did not start, so the config entry for XP shouldn't be
an issue.
Though I can see where the BIOS would need to have the drive
attached(and fully detected) if it's going to boot to it.
--
qemu -drive boot=on
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/48675413/Dependencies.txt
--
Syslog socket missing from chroot.
https://bugs.launchpad.net/bugs/582443
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in
Public bug reported:
Hello,
sshd attempts to open /var/run/sshd/dev/log in order to log events, but this
file did not exist.
I ran mkdir /var/run/sshd/dev and added $AddUnixListenSocket
/var/run/sshd/dev/log to /etc/rsyslog.d/75-ssh.conf. That should fix
things up.
ProblemType: Bug
My strace revealed that sshd was indeed attempting to open this socket
and failing. I can see where if a user can inject into sshd that
injecting into rsyslog would be trial for this person.
I don't fully understand the ramifications of extra code lying around to do
things like:
1. Test for the
Public bug reported:
Upgrading to saucy.
ProblemType: Package
DistroRelease: Ubuntu 13.10
Package: snmpd 5.7.2~dfsg-8ubuntu1 [modified: usr/sbin/snmpd usr/sbin/snmptrapd]
ProcVersionSignature: Ubuntu 3.11.0-17.31-generic 3.11.10.3
Uname: Linux 3.11.0-17-generic x86_64
ApportVersion:
33 matches
Mail list logo
