April 2015 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 925369] New: VUL-0: CVE-2014-2027: eGroupware before 1.8.006.20140217 allows remote attackers to conduct PHP objectinjection attacks, ...
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=925369 Bug ID: 925369 Summary: VUL-0: CVE-2014-2027: eGroupware before 1.8.006.20140217 allows remote attackers to conduct PHP objectinjection attacks, ... Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: 3rd party software Assignee: RalfBecker(a)outdoor-training.de Reporter: astieger(a)suse.com QA Contact: opensuse-communityscreening(a)forge.provo.novell.com Found By: Security Response Team Blocker: --- CVE-2014-2027 eGroupware before 1.8.006.20140217 allows remote attackers to conduct PHP object injection attacks, delete arbitrary files, and possibly execute arbitrary code via the (1) addr_fields or (2) trans parameter to addressbook/csv_import.php, (3) cal_fields or (4) trans parameter to calendar/csv_import.php, (5) info_fields or (6) trans parameter to csv_import.php in (a) projectmanager/ or (b) infolog/, or (7) processed parameter to preferences/inc/class.uiaclprefs.inc.php. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2027 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2027 http://openwall.com/lists/oss-security/2014/02/19/4 http://advisories.mageia.org/MGASA-2014-0116.html http://www.mandriva.com/security/advisories?name=MDVSA-2015:087 http://sourceforge.net/projects/egroupware/files/eGroupware-1.8/README/down… http://openwall.com/lists/oss-security/2014/02/19/10 Not in an openSUSE release, but in server:eGroupWare. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 919681] unable to create lxc container on an lvm
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=919681 Bugzilla Account Maintenance <autobugz> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|tbehrens(a)suse.com |bnc-team-screening(a)forge.pr | |ovo.novell.com Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chcao(a)suse.com Assignee|bnc-team-screening(a)forge.pr |jslaby(a)suse.com |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 925374] New: apcupsd drags along fontconfig libgd3 libjbig2 libjpeg8 libtiff5 libvpx1 libXpm4
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.opensuse.org/show_bug.cgi?id=925374 Bug ID: 925374 Summary: apcupsd drags along fontconfig libgd3 libjbig2 libjpeg8 libtiff5 libvpx1 libXpm4 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: per(a)computer.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I was trying to install apcupsd (as a client) on a xen host, i.e. text-mode only. It wanted to drag along: fontconfig libgd3 libjbig2 libjpeg8 libtiff5 libvpx1 libXpm4 Lots of graphics crud, for which this machine has no need. Seems to be dragged into by CGI functionality, perhaps %{apache_serverroot}/cgi-bin/upsimage.cgi. However, there is a apcupsd-cgi package, maybe those scripts belong in there. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 924818] Duplicates are NOT being removed from history in 13.1 when HISTCONTROL=erasedups is set
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=924818 David Rankin <drankinatty(a)suddenlinkmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(drankinatty@sudde | |nlinkmail.com) | --- Comment #4 from David Rankin <drankinatty(a)suddenlinkmail.com> --- Werner, agreed, this should be an upstream fix. I didn't know if a fix similar to the Ubuntu fix could be easily implemented. This is definitely a bug for me on 13.1. I generally have 5-8 bash session running simultaneousy in konsole for bash and C code. Here are additional details on the setup: $ rpm -q bash bash-4.2-68.12.1.x86_64 $ rpm -q --changelog bash | head -2 * Mon Oct 06 2014 werner(a)suse.de - Replace patches bash-4.2-heredoc-eof-delim.patch and $ rpm -qf /lib64/libhistory.so.6.2 libreadline6-6.2-68.12.1.x86_64 Global: $ cat /etc/bash.bashrc.local PATH=$PATH:/usr/sbin HISTCONTROL=ignoreboth:erasedups User: ~/.bashrc: export HISTFILESIZE=20000 export HISTSIZE=20000 export HISTCONTROL=ignoreboth:erasedups ## below: ignore space : ignore previous : ignore 1 : ignore 2 char cmds ## any pattern must match entire line (no presumed *) export HISTIGNORE=' *:&:?:??' confirming current environment $ env | grep HIST HISTSIZE=20000 HISTFILESIZE=20000 HISTIGNORE= *:&:?:?? HISTCONTROL=ignoreboth:erasedups For example concerning a .c file: Shell 1: $ history | grep ieee754cvt_2 12699 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 12700 ln -s ../../network/ieee754/ieee754cvt_2.c 12731 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 13341 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 13342 ln -s ../../network/ieee754/ieee754cvt_2.c 13373 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 13985 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 13986 ln -s ../../network/ieee754/ieee754cvt_2.c 14017 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 14391 grep manbits ieee754cvt_2.c 14669 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 14670 ln -s ../../network/ieee754/ieee754cvt_2.c 14701 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 16789 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 16790 ln -s ../../network/ieee754/ieee754cvt_2.c 16820 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 17461 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 17462 ln -s ../../network/ieee754/ieee754cvt_2.c 17492 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 18417 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 19105 history | grep ieee754cvt_2 Shell 2: $ history | grep ieee754cvt_2 12965 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 12966 ln -s ../../network/ieee754/ieee754cvt_2.c 12998 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 13606 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 13607 ln -s ../../network/ieee754/ieee754cvt_2.c 13639 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 14249 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 14250 ln -s ../../network/ieee754/ieee754cvt_2.c 14282 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 14658 grep manbits ieee754cvt_2.c 14935 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 14936 ln -s ../../network/ieee754/ieee754cvt_2.c 14968 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 17057 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 17058 ln -s ../../network/ieee754/ieee754cvt_2.c 17089 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 17730 mv ../../network/ieee754/ieee754-convert_2.c ../../network/ieee754/ieee754cvt_2.c 17731 ln -s ../../network/ieee754/ieee754cvt_2.c 17762 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 18700 cp iet.c ../io/network/ieee754/ieee754cvt_2.c 19331 g ieee754cvt_2 ieee754cvt_2.c 19332 ./bin/ieee754cvt_2 19335 history | grep ieee754cvt_2 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 910899] no output from logwatch
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=910899 Bugzilla Account Maintenance <autobugz> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|tbehrens(a)suse.com |bnc-team-screening(a)forge.pr | |ovo.novell.com Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chcao(a)suse.com Flags| |needinfo?(coolo(a)suse.com) --- Comment #2 from Chenzi Cao <chcao(a)suse.com> --- Hi Stephan, I'm seeking for a bugowner for this issue, would you please help here? Thank you! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 920205] mdcheck does not report errors in RAID5 array
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=920205 --- Comment #4 from Neil Brown <nfbrown(a)suse.com> --- One thing you could do straight away if you like is to write a little script to send you email and set it as MDADM_PROGRAM in /etc/sysconfig/mdadm Something like #!/bin/sh mail -s "md monitor message" root@localhost << END Array: $2 Event: $1 Extra: $3 END That will send you email for every event. You can obviously make it conditional if you like. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 921449] New: [ocfs2] cannot run run_reflink_test() case successfully on opensuse13.2 with ocfs2-tools-1.8.2
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=921449 Bug ID: 921449 Summary: [ocfs2] cannot run run_reflink_test() case successfully on opensuse13.2 with ocfs2-tools-1.8.2 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: lmb(a)suse.com Reporter: ghe(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This morning, I ran run_reflink_test() case again, and got the same result, the test node (open-nd1) was rebooted (do not know why? it did not look a system crash, just wonder if SBD killed the node? ). The ocfs2 cluster installation steps were written down in setup_ocfs2_cluster.txt. I launched the test with the command "./single_run-WIP.sh -k /data/linux-kernel.tar.gz -m /mnt/shared/ -l /opt/ocfs2-test/log -d /dev/mapper/cluster--vg1-big--lv -s pcmk -n hacluster", the other test cases were commented by me in single_run-WIP.sh script, for more details, please refer to opt.tar.gz file. the system message was dumped into messages.log. if you need more information, please tell me. for the problem that mmap_truncate test case when cluster_size=1M will hanged, I will reproduce it again and send back to you. rpm info: open-nd1:/opt/ocfs2-test/bin # uname -r 3.16.6-2-desktop open-nd1:/opt/ocfs2-test/bin # rpm -qa | grep ocfs ocfs2console-1.8.2+git.1361836695.ff84eb5-11.1.4.x86_64 ocfs2-tools-debuginfo-1.8.2+git.1361836695.ff84eb5-11.1.4.x86_64 ocfs2-tools-devel-static-1.8.2+git.1361836695.ff84eb5-11.1.4.x86_64 ocfs2-tools-devel-1.8.2+git.1361836695.ff84eb5-11.1.4.x86_64 ocfs2-tools-o2cb-1.8.2+git.1361836695.ff84eb5-11.1.4.x86_64 ocfs2-tools-1.8.2+git.1361836695.ff84eb5-11.1.4.x86_64 ocfs2-test-1.0.4+git.1423834151.6a0aacd-0.x86_64 open-nd1:/opt/ocfs2-test/bin # -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 920205] mdcheck does not report errors in RAID5 array
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=920205 Neil Brown <nfbrown(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #3 from Neil Brown <nfbrown(a)suse.com> --- (In reply to Peter van Hoof from comment #2) > > The script does not report mismatches. > > Detecting mismatches isn't really the point of running a 'check'. > > The main point is to read all block and make sure that none of them have gone > > bad (i.e. cannot be read). > > If any blocks are bad, they will automatically be fix (re-writing) if possible. > > If that isn't possible, the drive will be removed from the array. > > I don't think this is correct. My information is that a 'check' doesn't > repair anything. You need to run 'repair' to get the mismatches fixed. Any access the results in a read error will attempt to correct that read error if possible. The difference between 'check' and 'repair' is that if a 'mismatch' is found, then repair will repair it, but check will not. A 'mismatch' is where the parity calculated from the data disks does not match the parity stored on the parity block. This should be extremely rare. A read error is more likely. It seems I was wrong about mdadm --monitor sending mail for mismatches. If "--syslog" is enabled (which currently requires direct editing of the systemd unit file) then the mismatch count will be logged to systemd, but it is never emailed. I should probably change that. > At the moment I have > > # cat /sys/block/md2/md/mismatch_cnt > 16 > > from the April 1 check so I should have had an email from mdadm... I did a > manual repair of this RAID5 array last month, but obviously the problems are > back. I would love to know which disk is responsible for this so that I can > examine it more closely... It may not be one particular disk that is the problem, though that is certainly a possibility. It could be bad memory, or a problem with the drive controller, or maybe even a cable problem. My guess is that the controller is the most likely source of error, but I wouldn't trust that guess very much. The only way I know of to isolate this sort of problem is to replace component (or swap components between similar systems) until the problem disappears (or moved to the other system). -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 925535] airplane mode led illuminated on startup, airplane mode not enabled, does not correspond
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=925535 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chcao(a)suse.com Assignee|bnc-team-screening(a)forge.pr |os.gnome.maintainers@gmail. |ovo.novell.com |com --- Comment #2 from Chenzi Cao <chcao(a)suse.com> --- Hi there, would you please kindly help to have a look at here? I'm not quite sure whether it is right to assign it to you, please feel free to reassign whenever necessary, thank you! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 920205] mdcheck does not report errors in RAID5 array
by bugzilla_noreply＠novell.com 02 Apr '15

02 Apr '15

http://bugzilla.suse.com/show_bug.cgi?id=920205 Peter van Hoof <pvh(a)oma.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(pvh(a)oma.be) | --- Comment #2 from Peter van Hoof <pvh(a)oma.be> --- > The script does not report mismatches. > Detecting mismatches isn't really the point of running a 'check'. > The main point is to read all block and make sure that none of them have gone > bad (i.e. cannot be read). > If any blocks are bad, they will automatically be fix (re-writing) if possible. > If that isn't possible, the drive will be removed from the array. I don't think this is correct. My information is that a 'check' doesn't repair anything. You need to run 'repair' to get the mismatches fixed. > Mismatches *are* reported by "mdadm --monitor". > When "mdadm --monitor" notices that a check has finished it looks to see if > there were mismatches. If there were it sends email about it. This should > happen when the check finished because it came to the end of the array, or > when the check finished because it was stopped after 6 hours. > > "mdadm --monitor" is run by the "mdmonitor.service" systemd service, and should > be started whenever any mdarray is started. > > Do you have mdmonitor.service running? Yes. # systemctl status mdmonitor mdmonitor.service - MD array monitor Loaded: loaded (/usr/lib/systemd/system/mdmonitor.service; static) Active: active (running) since Tue 2015-02-24 01:20:32 CET; 1 months 6 days ago Main PID: 1083 (mdadm) CGroup: /system.slice/mdmonitor.service └─1083 /sbin/mdadm --monitor -d 60 -m root@localhost --scan -c /etc/mdadm.conf > Do you get mail sent to the MDADM_MAIL address in /etc/sysconfig/mdadm? My /etc/sysconfig/mdadm has default settings, so MDADM_MAIL="root@localhost". I am not receiving any mail there from mdadm. I just manually tested the mail account and it worked fine. At the moment I have # cat /sys/block/md2/md/mismatch_cnt 16 from the April 1 check so I should have had an email from mdadm... I did a manual repair of this RAID5 array last month, but obviously the problems are back. I would love to know which disk is responsible for this so that I can examine it more closely... -- You are receiving this mail because: You are on the CC list for the bug.

1 0