March 2014 - openSUSE Factory - openSUSE Mailing Lists

[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

[opensuse-factory] Releases going forward
by Robert Schweikert 31 Mar '14

31 Mar '14

Hi, Releases going forward, or, how do we release without full time paid worker bees? With all the discussion toward the end of last year I suppose that today's e-mail "Timeline and roadmap V2" [1] finally shed light on the inevitable conclusion, the openSUSE team (@SUSE) will spend more time on other stuff and less time, if any, on turning the release crank. This is the team's prerogative just like everyone is free to work on the project, or not, in areas of interest to them. We can argue whether the way this is coming about is giving the project the best chance to succeed or whether the transition is being put worth in a nice and friendly way, but I think we should not go down that path. Thanks! to the openSUSE Team for the hard work they have put forth in the past to turning the release crank, it is much appreciated. I think the time has come to move forward and deal with the new situation. As of right now we still have a release cycle of 8 month. That would put us into May for openSUSE 13.2. This brings about two questions: - Given the current situation can we meet a May release date? - Do we skip the May release and move to a yearly cycle and release 13.2 in November of 2014? During last year's discussions there were a number of people favoring a yearly release cycle. We have to make a decision, - stick to 8 month or move to 12 month? Voice your opinion but stick to the point and please be concise. For simplicity lets just assume that there will be no full time paid help to turn the release crank and that the work is all on those that are not part of the openSUSE Team. Under any circumstances I'd say our first go around will be a bit rough around the edges and that's OK, we have to learn. What do I have to offer? After all stuff will not get done by me sending an e-mail into the world. I offer to take on part of the role of "Release Manager". I will not be able to do all of it and I have a new definition for the role (see below.) Stephan did way more and was always the tireless worker that brought everything together. No one that does not work on openSUSE full time can obviously fulfill that role, thus we have to split things up. I figure there are about 60 to 70 hours worth of work per week that we have to distribute. I'll define "Release Manager" as: The person or group that runs after people, keeps an eye on the schedule and tries to herd the cats to get the stuff fixed that is broken. I am willing to take part of that role, and with this mail hopefully be a rallying point to put openSUSE releases on a bit more of a solid footing than where we are today, after [1]. If we go this route it implies that everyone that has stuff in Factory, what will become the next release, nothing there changes, has more responsibility in helping out than they do today. We no longer have people that can fix everything and get to spend all their time on the distribution and integration of stuff. Every maintainer has more responsibility. So where do we go from here? Do we bootstrap an effort to get a release out the door without openSUSE @SUSE or do we drift along in the uncertainty of "maybe we know something in August"? I am happy to be a rallying point and fulfill part of the role of "Release Manager" as outlined above. Maintainers/Packagers be heard, speak up, but lets not drift into rat holes, the situation is actually quite simple. Later, Robert [1] http://lists.opensuse.org/opensuse-factory/2014-01/msg00350.html -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

30 62

[opensuse-factory] kGraft @ 13.2 ?
by Matwey V. Kornilov 31 Mar '14

31 Mar '14

Hi, Will kGraft be supported for upcoming openSUSE release? Will the patches preparation be integrated into OBS? AFAIU, it is needed to produce special patch-module to load it, in order to fix something, so actual patch has to be wrapped around some kGraft-specific code to produce such a module. -- 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] Question about libzypp
by denisart benjamin2 31 Mar '14

31 Mar '14

Hello everyone ! Does somebody know why libzypp doesn't have anything like "yumdb set reason dep $PACKAGE" or "aptitude markauto $PACKAGE" ? Thanks -- 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] Status: Distribution
by Stephan Kulow 29 Mar '14

29 Mar '14

Hi, On Feb 24 I announced that factory reached 7000 packages, today is Mar 25 and I can tell you, we have 7100. And I'm hopeful that we can reach a more important milestone this week: having openqa.opensuse.org updated to new hardware and software, so you can finally see what I can see. When that's done, my plan is to tackle a revised Factory-Tested repo that will be the "new" factory. But the details are still to be checked, our priority is public openQA at the moment. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- 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] RFT: gnome-bluetooth-applet for Non-GNOME and Non-KDE desktops.
by Stefan Seyfried 28 Mar '14

28 Mar '14

Hi all, while checking for some graphical tool to configure bluetooth on desktops other than GNOME and KDE (I personally am very happy with command line bluetoothctl, but I see the need for something more colorful ;-), I came across two projects: * xfce4-bluetooth https://github.com/ncopa/xfce-bluetooth * gnome-bluetooth-applet https://github.com/City-busz/gnome-bluetooth-applet The first is just in its initial stage (means: you get an Icon and some dialogs, but cannot do anything useful with it, yet). It had a short burst of development action after it was started but now is silent without action for over 6 Months. The second is more useful: it is a fork of the gnome-bluetooth applet code from pre-GNOME-3.8, and only the applet code, apparently slightly forward ported to work with current gnome-bluetooth. This has some consequences: 1) it uses the well-maintained gnome-bluetooth stack (libgnome-bluetooth-applet.so.0, libgnome-bluetooth.so.12) for handling the low-level stuff (communication with bluez etc), the applet just displays an interface to gnome-bluetooth. In GNOME this is done by gnome-shell. 2) it needs gnome-bluetooth and friends, probably dragging in quite a big part of GNOME. I personally don't mind 2), since I have installed most of it anyway and disk is cheap, if it saves me from implementing all the dirty low-level stuff (most of which I cannot really test anyway). So what I would want to do is propose gnome-bluetooth-applet for inclusion in Factory and later maybe in the XFCE and other non-mainstream-desktop patterns, so that we can make bluetooth usable for more people out of the box. Right now I have packaged it in home:seife:bluetooth, it builds for 13.1 and Factory. If people interested in using bluetooth outside KDE or GNOME would test it and give feedback, then I can decide if it is worth polishing and getting ready for inclusion in openSUSE proper. add obs://home:seife:bluetooth to your repositories and try it! :-) Best regards, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 26

[opensuse-factory] 13.2M0 fails to boot
by Jogchum Reitsma 28 Mar '14

28 Mar '14

Hi, Iinstalled 13.3M0 on my "experiment disk" in my production system. One thing I changed in the suggested setup was that I placed the boot code on the root partition on that disk, instead of in the MBR of my first disk (which is part of the production disk set, so I don't want to fool around with that). Intallation went without a glitch, but it won't boot, complaining that /dev/root cannot be found. I am presented with the choice to seek it on /dev/dsf2 (the root partition of the experiment disk), but refuses to respond to the keyboard (except for Ctrl-Alt-Del, which leads to a reboot...). So I'm stuck here. Any thoughts? regards, Jogchum -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 16

[opensuse-factory] 13.2 M0: No DNS-settings via DHCP?
by Johannes Kastl 28 Mar '14

28 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, just installed the milestone in a qemu-kvm machine and started playing around. One thing I noticed: In the DNS and hostname settings in yast, "modify DNS settings" is always set to "Only Manualy". I do get an IP via DNS, but not nameservers. /etc/resolv.conf is empty (apart from the comments). The hostname seems to be set, although the yast dialogue shows "linux" as hostname. Regards, Johannes P.S.: Is there a 'known bugs in milestone 0' document available somewhere? - -- `Don't, Ginny, we'll send you loads of owls.´ `We'll send you a Hogwarts toilet seat.´ `George!´ `Only joking, Mum.´ (Harry Potter and the Philosopher's Stone) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlM0WvMACgkQzi3gQ/xETbK7AwCeIgnRyJd8Jpkgfz7XwTi9cYQs hn0An2kiRqLxgLYHSRs2NZ5BZUHb7QZB =yEbX -----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

2 1

[opensuse-factory] legacy actions in /usr/sbin/service
by Ludwig Nussel 28 Mar '14

28 Mar '14

Hi, Init scripts sometimes implement additional actions besides the usual start/stop/status etc. For systemd service files that extra feature doesn't exist. It's still convenient to have for some services though. Therefore /usr/sbin/service now implement "legacy actions" like Fedora. Suppose your previous init script "foo" had an action "frob". Now the service file is called "foo.service" and you want to still support that action. In Factory you can now create a script /usr/lib/initscripts/legacy-actions/foo/frob that implements the feature you need. Obviously the action is only available when calling the service via /usr/sbin/service, ie "service foo frob" or "rcfoo frob". cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0