April 2014 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] HEADS-UP: logrotate changes
by Cristian Rodríguez 08 Apr '14

08 Apr '14

Hi: Today an update to logrotate has hit the factory repositories and I think it is prudent to inform you all about some changes I added to the package and its side effects, either for documentation purposes or JFYI. ;) - Logrotate no longer runs as a cronjob but as a systemd.timer(5) - You can enable/disable log rotation by issuing systemctl enable/disable logrotate.timer - It continues to run just like "cron.daily" with the following bonus perks: * Log rotation will be postponed until your are connected to AC power, in order not drain your precious battery time. * The task will run as soon as possible in case your system was turned off, suspended or otherwise inactive at the time the process was scheduled (requires systemd 212 or later) * If any error is found, the results will be found in the journal (and/or syslog if installed) to see what's going on issue: systemctl status logrotate.service logrotate.timer Observed problems/gotchas: zypp installs packages in an unsuitable order, systemd-presets that enable the timer by default may be installed after the logrotate update. thus it does not get automatically enabled. to ensure things keep running smoothly in your factory installation: $ systemctl enable logrotate.timer $ systemctl start logrotate.timer Have a lot of fun :-) -- Cristian Team PITA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

15 41

[opensuse-factory] Switch to ifup from NetworkManager make system unusable
by Ken Schneider - Factory 07 Apr '14

07 Apr '14

Due to on going problems with NetworkManager not working for /me/ I changed to ifup method. The results created a system that was */NOT/* usable. I could not login to tty1 at all. Trying to use root resulted in an error that the login name was invalid. Trying to use my login name would not accept my password. Login via tty[2-6] would let me login but I would get auto-logged out after approximately 30 seconds making any effort to trouble shoot the problem fruitless. Fortunately I was able to ssh to the problem laptop and yast to change back to NetworkManager for the network and the system booted properly. openSUSE 13.1 --> Tumbleweed Toshiba Satellite L75D-A7288 Is anyone else seeing this problem? -- Ken Schneider -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] XWayland
by Dominique Leuenberger a.k.a. Dimstar 07 Apr '14

07 Apr '14

Hi all! GNOME 3.12.0 has been integrated into GNOME:Factory (submission to openSUSE:Factory due in time), and we started looking at the 'next wish on the list', coming from users, which happens to be GNOME on Wayland. In a branch, I configured the entire GNOME stack as required, without any big issues. There is one very important component missing though: * XWayland Seems our X Server in Factory does not know the -wayland parameter, and as a consequence, it is not possible to trigger a whole GNOME Session on top of wayland (using weston, it remains possibly to launch parts of it, but that's no fun). Are there any plans already to get XWayland into Factory as well? AFAIK, the code base has been merged into X Codebase after a three year effort (Kudos to the people hanging in there for so long). If this is no target for 13.2, then there won't be any reason for the GNOME Team to enable the stack neither of course; Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] Tumbleweed: libvirtd dead/inactive after laptop suspend?
by Johannes Kastl 06 Apr '14

06 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, can someone using Tumbleweed and libvirt confirm, that the libvirtd.service is not restartet after suspending a laptop? It starts ok when shut down and restarted, but is inactive after the laptop went to sleep and is woken up... Regards, Johannes - -- There are only two kinds of music: Rock and Roll. (Keith Richards) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlM/4FoACgkQzi3gQ/xETbLizACfUGNkXASxvm8k6klwZrvS2Sk8 V4sAoIvuPdkGaQCmgkh5Mg54hU0X0tYM =aUpE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 6

[opensuse-factory] pulsaudio, broken after kernel update
by C. Brouerius van Nidek 05 Apr '14

05 Apr '14

After the last zypper dup in Tumbleweed which mainly got me the latest kernel (see signature) my sound has gone. Pulseaudio is there, uses a lot of my cpu (22 to 60%). On my KDE desktop I have standard running kmail, chromium and skype (which of course is also not working) Remembering from the past i played around with Yast, sound and alsaconf. alsactl kill and alsactl start did nothing. A reboot with the second last kernel ( 3.14.0-22.g79de0a7-default) gave me my sound back and pulseaudio without cpu use. Am I the only one with this problem? A bug report? - - Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 13.1 (i586) Kernel: 3.14.0-23.gfa168d7-default KDE Development Platform: 4.12.3 14:54pm up 0:45, 4 users, load average: 2.80, 3.95, 4.64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 8

Re: [opensuse-factory] Re: grub2 vs. by-label
by Andrey Borzenkov 04 Apr '14

04 Apr '14

[sorry for accident off-list copy] В Wed, 2 Apr 2014 18:34:45 +0200 Olaf Hering <olaf(a)aepfle.de> пишет: > On Wed, Apr 02, Andrey Borzenkov wrote: > > > В Wed, 2 Apr 2014 18:23:08 +0200 > > Olaf Hering <olaf(a)aepfle.de> пишет: > > > On Wed, Apr 02, Andrey Borzenkov wrote: > > > > How exactly MBR signature or GPT GUID help here? > > > Not at all. At least grub has no concept of "use partition where the > > > files actually reside". Instead it has some odd device.map. > > > grub2 is (most likely) not any better. > > grub2 is using filesystem UUID to find partition where files actually > > reside. > > grub2 is the thing in /usr/*bin, not what runs in firmware context. > It is using OS device names. It will consult device.map only if called with deprecated (hdX) disk designation. openSUSE today puts /dev/disk/by-id in bootloader configuration. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 17

[opensuse-factory] HEADS up: GNOME:Factory breakae
by Dominique Leuenberger 04 Apr '14

04 Apr '14

Hi all, Just want to inform you that GNOME:Factory is currently seeing the integration of GNOME 3.12.0 (Factory targeted) and is due to this not in the best of shapes; I expect the builders to catch up shortly and have a stable repository published soon. The integration work had been done earlier in GNOME:Next, so in general we know what is coming and what is missing. Ensure to already read up on all the goodies GNOME 3.12.0 will bring you, like some redesigned apps (like gedit, videos, pocket integration into gnome-online-accounts...) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] grub2 vs. by-label
by Sascha Peilicke 04 Apr '14

04 Apr '14

Hi guys, our default grub2 configuration always uses UUIDs. For several reasons, I'd like to use labels instead but when looking at the scripts that generate /boot/grub2/grub.cfg it looks like UUID is more or less the only thing that works. So before I start tinkering with the scripts I'm curious if there is some prior art around already. -- Viele Grüße, Sascha Peilicke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 16

[opensuse-factory] tumbleweed: cannot build nvidia 331.49 for kernel 3.14.0
by Patrick Shanahan 04 Apr '14

04 Apr '14

kernel-desktop 3.14.0-23.1.g79de0a7 kernel-desktop-devel 3.14.0-23.1.g79de0a7 kernel-devel 3.14.0-23.1.gfa168d7 cannot build nvidia driver 331.49 for this kernel ??? test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2; \ echo >&2 " ERROR: Kernel configuration is invalid."; echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; full err logs @ http://wahoo.no-ip.org/~pat/nvidia-installer.log Anyone able? How? tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 11

[opensuse-factory] network install, but no network interfaces configured? iproute2 wasn't even installed?
by Per Jessen 04 Apr '14

04 Apr '14

I'm guessing that Factory is now supposed to work as a single-phase installation? Or do I still run /usr/lib/Yast/startup/Yast.ssh when the system boots the first time? On this system, no interfaces were configured on the first boot-up, and /usr/lib/Yast/startup/Yast.ssh didn't want to run because run_me_at_boot wasn't found. I tried "ip addr" to check the network interfaces, but iproute2 wasn't even installed? -- Per Jessen, Zürich (16.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 10

[opensuse-factory] manpage for 'lvcreate' -- does factory have info for thinpools?
by Linda Walsh 04 Apr '14

04 Apr '14

The utility 'lvs' has [--alloc AllocationPolicy] [--thinpool ThinPoolLogicalVolume{Name|Path}] [--poolmetadatasize Size[bBsSkKmMgG]] That don't seem to be in the manpage in 13.1... Is this fixed in factory? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 5

[opensuse-factory] Installation - no option to change hostname and domain?
by Per Jessen 04 Apr '14

04 Apr '14

I've just realised - yesterday when I installed Factory, I did not see the yast window which would enable me to set the hostname and domain. I think it also enables me to check the "change hostname via DHCP" box. Was this removed intentionally? -- Per Jessen, Zürich (11.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Re: Mesa for Tumbleweed
by Greg KH 03 Apr '14

03 Apr '14

On Thu, Apr 03, 2014 at 12:12:36PM +0200, langkamp(a)tomblog.de wrote: > > Greg KH <gregkh(a)linux.com> hat am 2. April 2014 um 00:37 geschrieben: > > > > > > On Wed, Apr 02, 2014 at 12:25:04AM +0200, Tobias Klausmann wrote: > > > (snip) > > > >>I'd suggest: > > > >> > > > >>X11:XOrg for Mesa 10.1 > > > >>https://build.opensuse.org/package/show/X11:XOrg/Mesa > > > >$ osc whatdependson openSUSE:13.1 Mesa standard i586 | wc -l > > > > 2003 > > > > > > > >Hah, yeah right, I'm not going to do that, sorry. > > > > > > > >>devel:tools:compiler for llvm 3.4 > > > >>https://build.opensuse.org/package/show/devel:tools:compiler/llvm > > > >I can add this, but is is really used by anyone? > > > > > > It is used to compile parts of/for Mesa, but with you not adding Mesa, it > is > > > more or less pointless to add it. > > > > Ok, I'll go remove it then, thanks. > > > > greg k-h > > Thanks greg for looking into this. I understand that it's too much work? It means I would have to have _all_ of 13.1 in the Tumbleweed repo. Things would be constantly rebuilding. I would have to do a lot more work, and Tumbleweed would be a stand-alone distro image at that point in time. And that's something I've said I was NOT going to do at all every time this has come up in the past. > Maybe the work would seem worthwhile when we know how many people would like > this update. So I opened a request on openFATE: > > https://features.opensuse.org/317173 > > I'll be back when a "reasonable" number of supporters votes this up :) So, it will somehow, because people want this, become more "managable"? That's not how things work, sorry. If you want the latest Mesa, try it in your own private repo and let me know how it goes. Or use the X11:XOrg repo. But given that this is a low-level library, with almost everything depending on it one way or the other, it is going to be tough going, sorry. best of luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 6

[opensuse-factory] net+ssh install - running yast just gives me .... yast ?
by Per Jessen 03 Apr '14

03 Apr '14

Previously, when installing over ssh, one only had to type/run 'yast', but this just ends up in the normal YaST menu. It looks like I now need to run 'yast.ssh', is that correct? -- Per Jessen, Zürich (16.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

[opensuse-factory] Mesa for Tumbleweed
by Thomas Langkamp 03 Apr '14

03 Apr '14

Would it be possible to have Meas 10.x and LLVM 3.4 in Tumbleweed? That would be really good for radeonSI users (OpenGL 3.1 instead 2.1) and is would be much appreciated since openSUSE 13.2 is delayed... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 9

[opensuse-factory] Grub2-EFI and GOP Support for UEFI Systems and 13.2
by Roman Bysh 03 Apr '14

03 Apr '14

Hello List mates, Now that new laptops and motherboards have switched to UEFI it is essential that GOP should be supported. Does any one know that Grub2-EFI for openSUSE 13.2 will add GOP support in the Yast Boot Loader? At the moment most people must add this manually to grub.cfg: insmod efi_gop insmod efi_uga insmod font if loadfont ${prefix}/unicode.pf2 then insmod gfxterm set gfxmode=auto set gfxpayload=keep terminal_output gfxterm fi Any thoughts? Cheers! Roman -------------------------------------------- openSUSE -- Get it! Discover it! Share it! -------------------------------------------- http://linuxcounter.net/ #179293 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 4

[opensuse-factory] Inclusion of Pitivi 0.92 and its dependencies to Tumbleweed
by Yonsung Lee 02 Apr '14

02 Apr '14

Hi all (first time mailing here, so pardon me if mistakes are made), The current version of Pitivi available for OpenSUSE:Stable is 0.15. It's buggy and limited, and was released in 2011. Since then, Pitivi has switched to using Gstreamer Editing Services (GES) as its platform, and its performance and stability has improved *exponentially*. The current stable release (0.92) is much more usable than 0.15. As far as I remember, there are two dependencies that need to be added as well, gstreamer-editing-services and GNonLin 1.1.90. Links to factory: https://build.opensuse.org/package/show?project=openSUSE% 3AFactory&package=pitivi https://build.opensuse.org/package/show?project=openSUSE% 3AFactory&package=gstreamer-editing-services https://build.opensuse.org/package/show?project=openSUSE% 3AFactory&package=gnonlin It would be great if this could be added to Tumbleweed, as we all know Linux users are in need of an intuitive yet versatile video editor. Thanks in advance, Y.L. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 6

[opensuse-factory] Finding a home for frescobaldi
by Cor Blom 02 Apr '14

02 Apr '14

Hi, For some time I am building frescobaldi[1] in my home project. I would like to move it on the road toward factory and am looking for a suitable devel project. Although the origin lies in KDE it is nowadays a Qt app. I would say multimedia:apps is a good project. If no-one objects or has other ideas, I will prepare a SR. Frescobaldi is a lilypond editor. Thanks, Cor [1] http://www.frescobaldi.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

Re: [opensuse-factory] Base:System util-linux, regarding sr 226509
by Stanislav Brabec 02 Apr '14

02 Apr '14

Ruediger Meier wrote: > On Friday 21 March 2014, Stanislav Brabec wrote: > > Ruediger Meier wrote: > > > Hi, > > > > > > The ChangeLog is almost useless since none of the referenced bug > > > reports is readable for non-suse people. > > > > These changelogs were taken from the original changelog. Many of > > openSUSE changelogs refer to bugs that are not accessible. In ideal > > case, people working on SLES fix would post the same patch to > > openSUSE, and make a public clone of the bug report. It did not > > happened, and a review found these patches, where the patch was not > > posted to Factory nor upstream. > > > > > At least one of the added patches ("umount-avoid-readlink.patch") > > > has no effect because it patches a deprecated and unused subdir > > > which will be removed in next release anyway. > > > > Yes, it is deliberate. The patch was created for SLE11 and affects > > the code, which is now deprecated and not used. I did not want to > > lose this patch and save it for upstreaming. > > Upstream has already removed the whole code. If upstream dropped "mount-deprecated" completely, then the patch as is is obsolete, and can be dropped now (or in the next version that will have no "mount-deprecated" code). > > Collecting upstream-able patches will take some time. Hopefully these > > patches will disappear from the Factory then. > > I'd like to help to get useful patches upstream. But it's hard if I'm > not allowed to know anything about the fixed issues. Well, there is also a lot of openSUSE patches, that need to check its universal validity. Regarding the SLES11 patches: sfdisk-warn-about-2TB-limit.patch: The msdos partition table is suppose to address up to 2 TB LUNs. Sfdisk didn't stop (or warning) the user about this limitation and went ahead created partition beyond 2 TB. After the reboot, the device node for the partition starting above 2TB was not created. Fix is impossible, but sfdisk should warn about it. The same bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324525 util-linux-ng-2.16-squashfs3-detect.patch: Detection of squashfs3 filesystem was requested. util-linux-ng-2.19.1-barrier_documentation.patch: The description of the 'barrier' mount option was request. Patch was written by Jan Kára. He wrote in the bug, that he sent the patch to the upstream as well. Maybe it was lost. util-linux-update-default-commit-interval.patch: Customer pointed out with the inclusion of the linux-2.6.29-jbd-longer-commit-interval.patch, changing "kjournald starting. Commit interval 15 seconds" from the long standing default "5 seconds", the "mount" man pages are no longer correct. Obsoleting of uuid-runtime: That package existed between SLE11 SP1 and SLE11 SP3 and probably sometimes in past. I failed to track the package origin, but it is safe to keep Obsoletes in the spec file. umount-avoid-readlink.patch: The problem existed (exists?) on NFS (reproduced on SLE11 SP2 on s390x, but probably was (is?) reproducible on all platforms): 1) sudo mount -t nfs4 -o sec=sys,intr,noac,nordirplus machine:/dir,binary /mnt 2) stop/reconfig NFS server 3) sudo umount -f /mnt umount2: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle umount2: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle sudo umount /mnt umount.nfs4: /mnt: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle File conflict: Package s390-32 contains files s390 and s390x conflicting with util-linux and breaks installation on System Z. uname26: There was a request to support uname26 in PAM (it already is) and have a simple to use uname26 binary. > > > Please somebody have a look at the last changelog and either make > > > the bug reports world-readable or fix the changlog to explain the > > > purpose of these patches: > > > > SLES bug reports that contain sensitive customer data cannot be > > opened for public. > > Have you really checked all the bug reports and they all contain > sensitive data? Well, if the bug is reported against SLES, there is no way to make it public in Bugzilla. The only way is making an openSUSE clone. Most of SLE bugs contain commercial support information, machine configurations and similar sensitive data. > > Most of these patches are self descriptive. Well, this one is > > probably not true for umount-avoid-readlink.patch: > > > > It's purpose is avoiding a readlink() failure when umount'ing stale > > NFS volumes. > > But today your patch only changes unused code. If this is still an issue > in the new code then your patch will not fix it. Volunteer reviewers > (like me) cannot really check if there is still an issue or not. Also > I'd like to check whether this patch would be good for Evergreen 11.4. I know. The code of umount is completely rewritten, and I was not able to determine, whether it is still needed. I plan to do test of these problems and then either port them or drop. > > > * lscpu: improve hypervisor detection (puzel(a)novell.com, > > > fate#310255) > > This patch for example breaks a test in the test suite. None of us can > read the discussion about this new feature. non-SLE people had no > chance to say their opinion about it. Patch was written by Petr Uzel. There was requested detection of all Hypervisors on x86_64, System Z and Power in lscpu and detect virtual graphic adapters. Adding him to Cc. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 8

[opensuse-factory] wow
by Peter Czanik 02 Apr '14

02 Apr '14

Hello, I just did a fresh installation of factory. Network manager in KDE displays an error, but networking seems to work fine. $SUBJECT is "wow" because I don't recall openSUSE booting ever so fast! What was changed? I did not check with a timer, but it seems to be faster now than other distros, while earlier openSUSE was among the slow starters. Not that it matters on a machine I turn on only once a day, but still :-) Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

11 25

[opensuse-factory] Re: Security issue: Proposal to revert to '/' on sep. part. from /usr,/home,/tmp,/var, etc
by Linda Walsh 02 Apr '14

02 Apr '14

Claudio Freire wrote: > Excuse the top posting, on a cell here and it's difficult to bottom post. --- Most gui email programs make it easier to put the most recent stuff at the top -- organizing a timeline from most-recent - older as you go down. Professions that need things organized chronologically tend to use this (medical, legal). Only those who think every detail is important, all the time, for everyone, force bottom posting. > I don't think patching the bare minimum is a good idea in this case... > the more restricting the rules are the less likely the issue remains > exploitable in yet unknown ways. --- Get rid of root entirely -- no exploits... Maybe cut the power as well. Let's take no halfway measures, eh? Um... you are changing system wide security policy. It seems like doing the minimum necessary to disable your exploit(s), is the best idea since every little bit that you change will cause more incompatibility for some program(s) somewhere -- not to mention this breaks posix rules, linux DACL rules, normal unix access restrictions, to name a few. > But maybe restrictions can be relaxed a bit to allow for your use case, > if it is common enough. Can you show an application that is broken by > current rules and that cannot be fixed without changes to the rules? ---- Can you show that your changes break no existing applications? You are proposing the changes but there's been no proof that any compatibility testing was done other than "ubuntu did it". Ubuntu, of course, is known to cater to the technically sophisticated users... who would be likely to use a variety of security scheme, right? Noooop. Ubuntu was designed for those coming from windows -- designed to take away decision points and make things simpler -- which I AGREE with -- but not at the expense of flexibility. I know the features can be turned off, BUT, Some vendors are designing new distro features based on the reduced functionality offered by the increased restrictions -- like putting everything on 1 partition. That used to be considered "bad system administration" and a bad practice for security, maintenance and reliability. It still is, but convenience is trumping everything else. > What you mentioned in the op seems a rather niche use you scripted > yourself and unlikely to be common. ---- Now here's where you are way off, as well as trying to create a self-fulfilling trap. ANY time you script something, it means you have a custom solution -- that by definition is a 'niche use'. If it could be done without a script, it would be a general use case implemented as a feature. Well guess what. There is no script involved. It's a general use case: "cp -al". I've been on many projects where one copy of the source was the pristine, read-only source, and people used links to create a low-space usage copy. This allowed them to create files as 'new files' where they made changes -- everything else was a read-only link enforced by it being a different UID. It may not be a common use case for home users, but for anyone who does development, it's among the simplest and easiest way to create a local "copy" that you can make changes to while keeping the overall disk cost low where you are re-using the original code. > For those cases specifically, there's a sysctl to disable hardlink > protection. ---- Actually, having the hardlink protections disabled are the default case. Opensuse turned them on in /usr/etc/sysctl.conf. Why wouldn't less overwhelming patch work? Specifically w/r/t prot.hardlinks: 1) cannot hard link to a setXID file unless you could create it yourself. 2) cannot link to/from a file in a world-writable sticky-directory. 3) Root privileges will not override sticky bit rules in the case of opening w/write. I.e. if a file already exists in temp owned by another user, root cannot open the file for write in 1 step. They must first either move or remove the sticky file. The latter step (3) makes the system safer than your proposed solution -- since as it is now, root can overwrite (accidently) any user created tmp file in /tmp, possibly destroying valuable work. ========================= Conversely -- specific criticisms of the new implementation: users can hardlink only to writable, regular files. The reasoning is to prevent race conditions and users writing into files expected to be used by root; BUT -- the new restrictions disable hardlinking to other file system objects -- in ALL CASES except where their UID=the object's UID. This disables Group control as well as control by access lists. A great deal of work has gone into making access lists viable -- and work went into making group access viable as well -- yet this disables both of those access methods for controlling hardlinking to writable objects (other than regular files). The irony, is that you can't have setXid objects other than *files* -- and the TOU exploits don't apply, EXCEPT to files... (i.e. they don't apply to hardlinking to symlinks, as you can't rewrite the symlink, they don't apply to other objects either -- named pipes? sockets? semaphores? None of those suffer from the TOU exploits -- yet they were all disabled unilaterally -- and don't even work when you have write access to those objects. ???? That doesn't make sense. If the idea was to protect against TOU problems, why disable linkability to other objects (besides files)? > If you can show a more widespread use case that is similarly affected, > that will encourage kernel developers to come up with less restrictive rules ---- The onus should be on those proposing the wide-ranging and incompatible new rules to prove why they are needed to the extent implemented. If no proof is needed, then just eliminate root, or pull the plug -- the former is practical with FLASK/SeLinux. But the problem is the bigger the change, the more things you break -- which is why I argue for the minimal change necessary. If you want a maximal solution, SELinux is already available. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] libwrap still broken over 2 years later...
by Linda Walsh 01 Apr '14

01 Apr '14

Just rebooted (it had been 60 days since last reboot), and it picked up the new tcpd/libwrap0 files from 13.1 (am pretty sure it's not fixed in factory, given it hasn't been fixed in over 2 years)... This is still a problem: http://lists.opensuse.org/opensuse/2011-10/msg00351.html Thought it was reported as I have a patch file... making sure it is reported here: https://bugzilla.novell.com/show_bug.cgi?id=861989 (had problems w/attachment, so am including it here as well..).

4 4

[opensuse-factory] Security issue: Proposal to revert to '/' on sep. part. from /usr,/home,/tmp,/var, etc
by Linda Walsh 01 Apr '14

01 Apr '14

WTF? Am I crazy? Following is a chain of logical events that have happened and are likely to happen that will cause even more security patches to compensate for the merge of '/' with other partitions (include /usr/share -- which was supposed to be independently sharable, yet the keyboard services needs it to load 'locales'). The conclusion is at the end, if you are one of those who are impaired with the TLDR disease. Well, yeah, and? The new setup is being used as a justification for a need for a new and ill designed security feature: "protected_hardlinks" that disables standard, legacy linking ability. In 13.1, this feature is turned on by default. That causes side effects, like not being able to copy a R/O source-tree with "cp -al", into a 2nd copy of symlinked dirs w/hard-linked file objects. To me, that was a basic source control mechanism -- anything that was the same between the two (or 20 trees) shared the same file and was read-only as someone other than the owner of the original source tree (often root). Local mods in source files could be made in your source tree but they wouldn't propagate to to the source copy. Now, such a setup is impossible in the default suse config unless a user has access to root and/or is willing to risk overwriting the original source. The main justification for protected_hardlinks was to protect users from linking to files that used to be on *separate* file systems (/etc/{shadow,group,passwd}) to use for some further exploit -- claim a lost of files and a need for their homedir to be restored via some util that writes to a hardlinked file w/root privs, for example. But now, along comes the protected_hardlinks feature which doesn't do the same job. It allows linking, only, to _regular files_ that you have write access to. Logically, to get around the inability to link w/o write access, one might think to make sure the copying user is in the same group as the target files and use group write access. That causes 2 problems: 1) it doesn't solve the original requirement of keeping the original source tree read-only to other users (i.e. if the users have write access through the group, they can overwrite the original, but worse, 2) protected_hardlinks was implemented to inconsistently allow hardlinking to objects in in the source tree. While it used to be the case that one could hardlink to any readable non-directory on the same device, protected_hardlinks changes that to allow hard-linking not just to "writeable" files, but only *regular files*. This means for example, that the kernel source tree can no longer be copied by anyone other than the tree owner due to symlink usage in the kernel (that were previously hardlinked to): > find . -type l|xargs ls -dgGl|cut -c30-999 ./arch/arm/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/metag/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/microblaze/boot/dts/system.dts -> ../../platform/generic/system.dts ./arch/mips/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/powerpc/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings Of less commonality, but also affected were hardlinks to named pipes, sockets, -- any other file system object -- except for dirs which, on linux, have pretty much always been disallowed. Notably, now, we have a broken workaround to re-create security lost by previously having a separate root (broken in that it only partly works for some objects), but it's already being discussed how utility (applications will have to follow) progs will deal with making copies when "cp -al" is used -- i.e. it is likely that linux will fall back to DOS-level functionality where copies are made for any file object that doesn't support linking. This has a further security impact: any ACL's or security labels on a readable file will be stripped unless the copying user has the ability to recreate them (often not true if the source tree was designed to be read-only to the copier). I found that to already by a problem when 'mv'ing files -- a few samba versions mistakenly put NT-acl's in the 'security' or 'system' namespace, when such ACL's are not native acls, but a user-app (samba) level data-blob. That issue was raised with the samba team, and it appears it will be addressed, though no official statement was made about the security hole (a Windows user who has login access to the domain will be able to, by default, strip the file of it's NT-ACL just by moving it to another partition or by copying it (whether they intend this or not -- it's not a good side-effect). ========================= **TLDR: In short, the joining of the partitions has already caused broken security workarounds to go into the kernel (that still need to be fixed), and is in the process of requiring system utils and applications to invent workarounds for the security implications -- that themselves cause their own set of security issues that will need more patches, and likely cause more rounds. I.e. this is a case of a bad decision causing a chain of worsening and growing side effects. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 7