March 2012 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 313167] More "sane" dependencies for packages
by fate_noreply＠suse.de 31 Mar '12

31 Mar '12

Feature added by: Chris Brown (katanacb) Feature #313167, revision 1 Title: More "sane" dependencies for packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Chris Brown (katanacb) Partner organization: openSUSE.org Description: More sane dependencies in the distribution. The dependencies for openSUSE's packages don't seem to make sense. I've posted a few times on the openSUSE message boards about this, but I don't understand why i need iPhone libraries for ksnapshot, or why I need evolution libraries in (what I want to be) 100% pure KDE distribution. Deleting them is a day-long walk-through with YaST and resolving dependency problems that IMHO shouldn't be there in the first place. Other distributions don't have this same problem, so it's something to do with packaging in this distribution. I'm not slamming the developers for this, I'm just saying that some of the library and application dependencies don't seem to make sense and should maybe be looked at a bit closer. -- openSUSE Feature: https://features.opensuse.org/313167

1 2

[New: openFATE 309704] add libzypp capability to extend LVM on demand
by fate_noreply＠suse.de 30 Mar '12

30 Mar '12

Feature added by: Dinar Valeev (k0da) Feature #309704, revision 1 Title: add libzypp capability to extend LVM on demand Requested by: Dinar Valeev (k0da) Description: LVM is designed to mange your disks in flexible way. This means, allocate and use only needed space. And keep unallocated space for further tasks. It would be great if libzypp can extend logical volume on demand (space required for package installation is already known) Scenario: 1)there are logical volumes within VolumeGroup (/var, /usr,/tmp) 2)VolumeGroup have free PhysicalEextents 3)logical volume have no free space for package install 4)Install package/packages which requires 12Mb in /tmp, 40Mb in /usr and 16Mb in /var 4)libzypp will extend logical volumes and file systems /tmp by 3 Logical extend, /var by 10 le and var by 4le -- openSUSE Feature: https://features.opensuse.org/309704

1 4

[openFATE 305015] support noarch via own scheduler in Build Service
by fate_noreply＠suse.de 30 Mar '12

30 Mar '12

Feature changed by: Claudio Freire (klaussfreire) Feature #305015, revision 7 Title: support noarch via own scheduler in Build Service Buildservice: Evaluation by engineering manager Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: We would like to build noarch packages only once to avoid multiple builds and wasted space on the server. This can be reached by building noarch packages only via an dedicated scheduler. However, we need to avoid that have a horrible project configuration, where all BuildRequired noarch packages needs to get submitted into all other architecture repository :full trees. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:48:58) Theoretically already possible, still questionable if we want this. -> keep it in evaluation #2: Greg Freemyer (gregfreemyer) (2012-03-30 20:14:05) I can think of of at least 3 ways to accomplish the goal: 1) Allow noarch builds of just one arch to be accepted to factory. Then encourage people to just enable one arch. Hopefully randomly to spread the load around. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). idea 1) seems relatively doable for a modest effort. idea 2) would require changes lots of places I assume, so it is not trivial. idea 3) seems like the least work by far, and it sheds work load from one of the schedulers. I don't know if that would benefit the overall OBS load or not. And I'm sure there are other ways. === The question is if the wasted build resources is worth the R&D to bother with fixing this. + #3: Claudio Freire (klaussfreire) (2012-03-30 20:30:05) (reply to #2) + 3) Enforce in all schedulers but one, that they ignore noarch + packages. Then document that so everyone knows they can only build + noarch on i586 (as an example). + I think this is the best option. + For one, making sure noarch packages are built in the same architecture + every time will help avoid spurious deltas: if a package builds + differently on different architectures, but the packager decided that + the difference is inconsequential. For instance, arm zlib needs not + produce the same output as x86 zlib. + For two, i586 and x86_64, AFAIK, use the same hosts. Right? So + spreading the load among those two is useless. + But there are quite a few caveats. One, people should not care about + which arch is enabled, if there is any enabled archs for a noarch + package, it should be built by "the noarch" scheduler (say, the x86_64 + scheduler). If there are many archs enabled, only one build should be + scheduled, and build results should be replicated. This might need some + doing. + 2) Create a new "noarch" architecture and scheduler. Have that feed + whatever actual scheduler has the lightest load at schedule time. That + way even non-Intel machines could build the noarch packages. + So, more to-the-point would be option 2, but it still doesn't + completely convince me, because it would be quite confusing in the UI. + There also option 1, which I guess would work for factory (but not + other projects). It's already common practice in OBS to only enable one + arch for big noarch packages, so it should be rather easy to do - just + fix factory-auto's validation script to account for noarch packages. + About the benefits, I have a few projects that build hundred-MB noarch + rpms with game data. Those take a lot of I/O resources to build, so the + inefficiency (in that case) is significant. I'm not sure about how many + projects are found in that situation, though. + I would vote to get option 1 implemented ASAP - it should be easy and + immediate. If I wanted to patch it... where should I go to find the + factory-auto script? -- openSUSE Feature: https://features.opensuse.org/305015

1 0

[openFATE 305015] support noarch via own scheduler in Build Service
by fate_noreply＠suse.de 30 Mar '12

30 Mar '12

Feature changed by: Greg Freemyer (gregfreemyer) Feature #305015, revision 6 Title: support noarch via own scheduler in Build Service Buildservice: Evaluation by engineering manager Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: We would like to build noarch packages only once to avoid multiple builds and wasted space on the server. This can be reached by building noarch packages only via an dedicated scheduler. However, we need to avoid that have a horrible project configuration, where all BuildRequired noarch packages needs to get submitted into all other architecture repository :full trees. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:48:58) Theoretically already possible, still questionable if we want this. -> keep it in evaluation + #2: Greg Freemyer (gregfreemyer) (2012-03-30 20:14:05) + I can think of of at least 3 ways to accomplish the goal: 1) Allow + noarch builds of just one arch to be accepted to factory. Then + encourage people to just enable one arch. Hopefully randomly to spread + the load around. 2) Create a new "noarch" architecture and scheduler. + Have that feed whatever actual scheduler has the lightest load at + schedule time. That way even non-Intel machines could build the noarch + packages. 3) Enforce in all schedulers but one, that they ignore noarch + packages. Then document that so everyone knows they can only build + noarch on i586 (as an example). idea 1) seems relatively doable for a + modest effort. idea 2) would require changes lots of places I assume, + so it is not trivial. + idea 3) seems like the least work by far, and it sheds work load from + one of the schedulers. I don't know if that would benefit the overall + OBS load or not. + And I'm sure there are other ways. === + The question is if the wasted build resources is worth the R&D to + bother with fixing this. -- openSUSE Feature: https://features.opensuse.org/305015

1 0

[New: openFATE 313369] Block outgoing TCP connections on the firewall.
by fate_noreply＠suse.de 28 Mar '12

28 Mar '12

Feature added by: Jonata Pérez (jony127) Feature #313369, revision 1 Title: Block outgoing TCP connections on the firewall. openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Jonata Pérez (jony127) Partner organization: openSUSE.org Description: It would be interesting that opensuse's firewall can block outbound connections tcp/udp as it enable ufw or fwbuilder. Use Case: Need to block specific outgoing connections. Business case (Partner benefit): openSUSE.org: Improve potency opensuse firewall. -- openSUSE Feature: https://features.opensuse.org/313369

1 1

[New: openFATE 312617] drop libxcrypt
by fate_noreply＠suse.de 20 Mar '12

20 Mar '12

Feature added by: Ludwig Nussel (lnussel) Feature #312617, revision 1 Title: drop libxcrypt openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: libxcrypt is nowadays mostly superfluous as glibc supports sha256 and sha512 itself. blowfish and the gensalt functions can be patched in via crypt_blowfish addon. Needed adjustments: - pam [done] - pam-modules (pam_unix2) [done] - pwdutils [done] - yast Disadvantage: we currently lose support for bigcrypt. -- openSUSE Feature: https://features.opensuse.org/312617

1 9

[openFATE 302047] Integrated package searching for YaST and build service
by fate_noreply＠suse.de 19 Mar '12

19 Mar '12

Feature changed by: Martin Seidler (pistazienfresser) Feature #302047, revision 40 Title: Integrated package searching for YaST and build service openSUSE-10.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2007-10-05 14:30:28 reject reason: still open partly - postpone the rest. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Michael Loeffler (sprudel24) reject date: 2008-06-10 14:01:45 reject reason: not done for 11.0 Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter (adriansuse) reject date: 2008-09-04 18:17:10 reject reason: No time for it, but we have the one-click installation supported from web interface. Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-11-08 16:58:51 reject reason: Not done for 11.3. Priority Requester: Desirable openSUSE-11.4: Unconfirmed Priority Requester: Desirable openSUSE Distribution: New Priority Requester: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: Michael Loeffler (sprudel24) Technical Contact: Andreas Bauer (abauer12345) Partner organization: openSUSE.org Description: You perhaps remember the hacks Benjamin did to support "click and install" packages (similar to Click'n run) [1] Benjamin has another article in his blog that is worth to read. He has been providing a wepage to search packages from repositories like packman and build service. Now he presents an architecture to desentralize the system, using web services an indexers, and he shows working prototypes of YaST modules for searching, and others like web and irc-bot clients http://blogs.warwick.ac.uk/bweber/entry/package_search_developments/ I hope we can provide a strategy and roadmap to integrate these cool ideas and _code_. [1]: http://blogs.warwick.ac.uk/bweber/entry/next_generation_package/ Discussion: #1: Juergen Weigert (jnweiger) (2007-05-03 15:29:13) see also 300898 For 10.3 the installer should be able to make use of an external list of repositories. I suggest to host such a list at http://packages.opensuse-community.org/ together with the search engine, which is already there. #3: Klaas Freitag (kfreitag) (2007-07-12 10:46:54) Implementation on openSUSE BS already started, Adrian knows the details. #4: Adrian Schröter (adriansuse) (2007-07-12 11:30:04) We work on two approaches atm: * YaST will support (thanks to mvidner) additional repository offers during installation. The list gets hosted on our servers, the open question is how to maintain this list. * The build service End-User interface will offer .ymp files based on pattern submissions for easy installation. #5: Stanislav Visnovsky (visnov) (2007-07-30 20:13:09) (reply to #4) Adrian, please, drive this. The feature for YaST should be done now (let me know if anything is missing). #6: Michael Loeffler (sprudel24) (2007-11-22 11:26:30) This sounds like very useful. And it might be possible the community (in this case Benji) helps implementing this. #7: Andreas Jaeger (a_jaeger) (2008-06-06 10:56:28) Apparently not done - please reject and postpone for 11.1. #9: Adrian Schröter (adriansuse) (2008-06-18 17:08:16) This is something what we should bind to the new upcomming software portal. The software portal will be the End-User interface for searcing and installing software and replace http://software.opensuse.org/search . However it is still in development and not yet set up. Therefore I am unsure if this can happen in time for 11.1. On the other side, the 1-click-installation and integration into the web interface is done since quite some time. The user can use the cool technologies from Benjamin since 10.3. #10: Andreas Jaeger (a_jaeger) (2010-12-02 15:31:30) This should be done with a software portal. + #11: Martin Seidler (pistazienfresser) (2012-03-19 09:09:39) (reply to + #10) + And a software portal with this features is now in the testing/implantation + phase(s). + See for more information on the mailing list of the buildservice: + [opensuse-buildservice] Reworking the software search + (http://lists.opensuse.org/opensuse-buildservice/2012-03/msg00001.html) started + at Thu, 01 Mar 2012 12:05:35 +0100 [opensuse-buildservice] Reworking + the software search, part II + (http://lists.opensuse.org/opensuse-buildservice/2012-03/msg00053.html) stared + at Mon, 12 Mar 2012 16:41:26 +0100 + Thanks to all involved! + Martin -- openSUSE Feature: https://features.opensuse.org/302047

1 0

[New: openFATE 312841] Cleanup old uploaded sources in Open Buildservice
by fate_noreply＠suse.de 18 Mar '12

18 Mar '12

Feature added by: Carsten Hoeger (choeger) Feature #312841, revision 1 Title: Cleanup old uploaded sources in Open Buildservice Hackweek VII: Unconfirmed Priority Requester: Important Requested by: Carsten Hoeger (choeger) Partner organization: openSUSE.org Description: Uploaded sources cannot be removed from Open Buildservice. This results in disks filling up. Business case (Partner benefit): openSUSE.org: Does not makes sense to buy new disks for code that will never be accessed again. -- openSUSE Feature: https://features.opensuse.org/312841

1 1

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 18 Mar '12

18 Mar '12

Feature changed by: Martin Seidler (pistazienfresser) Feature #305657, revision 60 Title: finer grained PolicyKit support for Networkmanager openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-11-19 12:53:01 reject reason: not in release Priority Requester: Important Projectmanager: Desirable Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup Discussion: #1: Matthias Nagorni (mnagorni) (2009-08-21 14:26:22) If this can be done with little effort I would be even tempted to rate it Mandatory. #2: Stefan Behlert (sbehlert) (2009-08-25 16:37:57) Alex, is there soemone on your team who could look at that? MAybe with some support form Tambet? #3: Li Bin (binli) (2009-08-26 05:58:01) I and lance wang would like to take care of it. We still don't know the requirement clearly. 1. disallow workers on centrally administered machines to configure different network settings The workers mean the users in administered machines? Does it right that when workers configure network settings it prompt they are no permission? If so I thought we could change the PolicyKit's configuration file to complete it. 2. protect home users that only ever connect to a few well known nets from accidently changing their setup How to distinguish home users from workers? Does it mean don't allow the user to configure the other users connections? #4: Ludwig Nussel (lnussel) (2009-08-26 08:40:53) (reply to #3) Currently there's only org.freedesktop.network-manager-settings.system. modify, introduce something like org.freedesktop.network-manager- settings.user.modify so NM can determine whether it should accept user settings. #16: Wang Lance (lzwang) (2009-09-25 11:26:20) (reply to #4) Hi Ludwig Nussel I have added the following policy action: org.freedesktop.network-manager-settings.user.wired.apply org.freedesktop.network-manager-settings.user.wireless.apply org.freedesktop.network-manager-settings.user.mobile.apply org.freedesktop.network-manager-settings.user.vpn.apply org.freedesktop.network-manager-settings.user.dsl.apply . NM now can determine whether it should apply the user settings to devices by type. Does the implementation meet your request? I need your feedback to determine what should to do next step. Thanks, Lance Wang #17: Ludwig Nussel (lnussel) (2009-09-25 11:58:50) (reply to #16) Sure, that's even more than I had wished for. Would it be possible to also have a separate privilege for the connection sharing thingy? In contrast to the other configurations that one also messes with iptables and starts a DHCP daemon. #5: JP Rosevear (jproseve) (2009-08-26 17:06:51) (reply to #3) My suggestion would be to look at something like the following: org. freedesktop.network-manager-settings.system.modify org.freedesktop. network-manager-settings.system.add org.freedesktop.network-manager- settings.system.delete and the same for .user - you may even want to specifically allow or disallow adding for specific network types like wired, wireless, etc. You probably also want to have the ability to enable/disable wireless in general and enable/disable networking covered. You can default all of these to the current settings, but adding these would allow more lockdown opportunities. #6: Li Bin (binli) (2009-08-31 11:22:12) Well, We'll works on this feature in this week, know about the PolicyKit and NetworkManager, write the patch if time is okay. Tambet, Do you have any idea about this feature? #7: Luis Medinas (lmedinas) (2009-08-31 18:40:51) (reply to #6) Might worth looking at NM 0.8 (git master), it supports the latest polkit-1 and it should be released before 11.2. Maybe some of this features were introduced. #8: Tambet Ingo (tambet) (2009-09-01 09:40:05) (reply to #7) NM 0.8 will not be out before 11.2, it'll be out for the next Fedora release which will happen after 11.2. Also, current git master does not have any work for this feature, it's just been converted to use the newer, incompatible polkit API. #9: Tambet Ingo (tambet) (2009-09-01 09:43:56) (reply to #6) The upstream has been planning on having similar feature for a while now, but no work has been done on it yet. I strongly suggest to have a discussion with the upstream maintainer before any work gets done, otherwise our effort might end up thrown away as soon as upstream implements it. #10: Li Bin (binli) (2009-09-01 09:14:24) Yes, I talk with the upstream today, just wait for response. You can follow it from below link. Thanks! http://mail.gnome.org/archives/networkmanager-list/2009-September/date.html #11: Stephan Kulow (coolo) (2009-09-07 13:39:17) (reply to #10) didn't see a lot of replies. #12: Li Bin (binli) (2009-09-10 05:24:05) The upstream maintainer Dan already reply this issue, and it's no user case for seperating add, modify and delete permission, and the others was agreed. Lanc wang with me work the sled11 and upstream now, we'll provide a patch in this week. #13: Wang Lance (lzwang) (2009-09-15 08:10:43) Hi I add five policy like the following : org.freedesktop.network-manager- settings.system.wired.modify org.freedesktop.network-manager-settings. system.wireless.modify org.freedesktop.network-manager-settings.system. mobile.modify org.freedesktop.network-manager-settings.system.vpn. modify org.freedesktop.network-manager-settings.system.dsl.modify. As you know there will be one policy one type. I make a patch which works. But I feel a little confused on the user settings. As the user settings are saved in the gconf, so adding someting like manager- settings.user.*.modify make no sense. As far as I know user can always edit their gconf settings. I think what should be done may be the policy that determine if the users can apply their settings to the system devices throught dbus. Given we do it like that, should the nm-applet display the user setting in the menu, when a normal user can not apply his or her settings to system devices? I think it is better that nm-applet show both system settings and user settings, and it will show error dialog if a user try to apply user settings when the user does not have the right do that. Hi Tambet, what do you think? #14: Li Bin (binli) (2009-09-17 11:18:37) (reply to #13) Tambet reply in the mailinglist, we just lock the /system/networking path in gconf and the settings can't be changed. #15: Michael Meeks (michael_meeks) (2009-09-23 16:55:40) We should also add the case mentioned in bug #522742 - to allow disabling the "Create new wireless network" functionality. This is of particular concern to the security team, and I'd like to see it addressed as part of the same work if possible. Otherwise, this looks great - thanks Li Bin :-) #18: Li Bin (binli) (2009-09-25 12:03:28) (reply to #15) Michael, I've viewed the bug#522742, it talk more about sharing, and we don't need to disable "Create new wireless network", user can add it, but when they wanna to apply it by click the connection, check org. freedesktop.network-manager-settings.user.wireless.apply permission like the Lance describe in #16. Does it okay? #19: Michael Meeks (michael_meeks) (2009-09-28 10:10:26) (reply to #18) No - connecting to a new wireless network is -very- different from sharing all your existing connections over your current wireless network; I can see why people would want to allow one and not allow the other. We should (ideally) have a different policy setting for this - if possible. Thanks #25: Wang Lance (lzwang) (2009-10-28 11:49:58) (reply to #15) Hi Michael I have read bnc #522742. And it is about sharing network. I wonder that why only the "Create new wireless network" need a policy, since all kinds type connection can be shared. As far as I know in nm-applet 7.0 the "Create new wireless network" is only for adhoc wireless connection. Did you mean that sharing adhoc wireless connection have security problem? And other type connections do not ? Thanks, Lance Wang. #20: Tanja Roth (ta-ro) (2009-10-05 15:01:26) Can you please confirm what the final policy names (identifiers) are going to be for 11.2 and what can be influenced with them? (a short description as available from the Description field in polkit-gnome- authorization would be sufficient). I would like to mention this in the 11.2 docs about NetworkManager, but so far, I only found the one policy that relates to modifying administrator defined connections (org.freedesktop.network-manager- settings.system.modify). From your comments above I'm not sure if the names mentioned in #16 are the final ones for the newly added policies (and if the list is complete). Please advise asap as the translation deadline for this chapter is approaching. Thanks! #22: (binli) (2009-10-12 11:27:53) (reply to #20) Tanja, Just come back from holiday, sorry for late. Now this feature is still not in the upstream, I'm still working on it. I prepare to seperate the permission into more fined like, org.freedesktop.network-manager-settings.system.wireless.modify - Modify system wired connections org.freedesktop.network-manager-settings.system.wired.modify - Modify system wireless connections the description follow the policy. The #16 is now for the SLED 11-SP1 for temporary resolving usercase, I'm not sure if it could be received by upstream which is used for 11.2. So what's your translation deadline? I'll inform you when I confirm it with upstream. #23: (ta-ro) (2009-10-12 12:25:30) (reply to #22) Lin Bi, thanks very much for clarifying! :) Our localization deadline is Oct 15th but as the files have to go through language proofreading before, I have to finish the chapter today, I'm afraid. But don't worry, to be on the safe side (whatever the upstream decision may be), we can handle it as follows: for now, I'll only mention that there *are* policies for NetworkManager and where to find them in PolicyKit. We can then add more details for the next release of the docs (presumably SLE 11 SP1). #24: (ta-ro) (2009-10-12 13:18:21) (reply to #23) Removing the needinfo status. #26: Wang Lance (lzwang) (2009-11-02 08:51:11) Hi Ludwig Nussel Could you test this new functions in SLED11. I made the packages with the function. These are the URLs https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… I implemented the following policy: "org.freedesktop.network-manager-settings.system.wired.modify" "org. freedesktop.network-manager-settings.system.wireless.modify" "org. freedesktop.network-manager-settings.system.mobile.modify" "org. freedesktop.network-manager-settings.system.vpn.modify" "org. freedesktop.network-manager-settings.system.dsl.modify" "org.freedesktop.network-manager-settings.user.wired.apply" "org. freedesktop.network-manager-settings.user.wireless.apply" "org. freedesktop.network-manager-settings.user.mobile.apply" "org. freedesktop.network-manager-settings.user.vpn.apply" "org.freedesktop. network-manager-settings.user.dsl.apply" . And *.modify are the policy for the editing adding and deleting of the system connections. And *.apply are the policy for applying the user connection to activate the devices. You can see the default settings in /usr/share/PolicyKit/policy/org. freedesktop.network-manager-settings.system.policy, which make the NM behave like the one without those policy. Thanks, Lance Wang #27: Ludwig Nussel (lnussel) (2009-11-03 16:17:45) (reply to #26) I've tried it on openSUSE 11.1 now. Works great AFAICT. However I think the usability could be enhanced by creating system connections by default, at least when user connections are restricted. That way the user would not need to authenticate each time he wants to connect. wrt separate policy for shared connections, I think that should be doable by checking another condition in is_user_request_connection_type_authorized(), right? #28: Wang Lance (lzwang) (2009-11-06 10:52:31) (reply to #27) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1. Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2. Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager- settings.system.*.modify. 3. In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4. Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he have the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1. If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2. If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3. If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org. freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? #29: Wang Lance (lzwang) (2009-11-06 11:02:46) (reply to #27) (sorry. repeat reply for missing format) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1) Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2) Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager-settings.system.*. modify. 3) In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4) Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he has the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1) If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2) If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3) If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org.freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? #30: Ludwig Nussel (lnussel) (2009-11-06 11:09:33) (reply to #29) Ok. I already suspected that the system setting thing is hard to do with NM's architecture. Wrt share settings I'd set them to auth_admin_keep_always by default. However, the settings you add to the package get overwritten by polkit- default-privs anyways to be able to use different settings for 'standard' and 'restrictive'. #31: Wang Lance (lzwang) (2009-11-11 11:49:59) Hi Ludwig The version with shared connection is ready. These are https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… The policy added are org.freedesktop.network-manager-settings.user.*.apply- with-share. What should be mentioned is that the shared connection is only controlled by these. In other words org.freedesktop.network- manager-settings.user.*.apply do not control the shared connection. Thanks, Lance Wang + #35: Martin Seidler (pistazienfresser) (2012-03-18 17:01:50) + What is the status of this feature now? + Regards Martin -- openSUSE Feature: https://features.opensuse.org/305657

1 0

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 18 Mar '12

18 Mar '12

Feature changed by: Martin Seidler (pistazienfresser) Feature #305657, revision 59 Title: finer grained PolicyKit support for Networkmanager - openSUSE-11.2: Rejected by (sbehlert) + openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-11-19 12:53:01 reject reason: not in release Priority Requester: Important Projectmanager: Desirable Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup Discussion: #1: Matthias Nagorni (mnagorni) (2009-08-21 14:26:22) If this can be done with little effort I would be even tempted to rate it Mandatory. #2: Stefan Behlert (sbehlert) (2009-08-25 16:37:57) Alex, is there soemone on your team who could look at that? MAybe with some support form Tambet? #3: Li Bin (binli) (2009-08-26 05:58:01) I and lance wang would like to take care of it. We still don't know the requirement clearly. 1. disallow workers on centrally administered machines to configure different network settings The workers mean the users in administered machines? Does it right that when workers configure network settings it prompt they are no permission? If so I thought we could change the PolicyKit's configuration file to complete it. 2. protect home users that only ever connect to a few well known nets from accidently changing their setup How to distinguish home users from workers? Does it mean don't allow the user to configure the other users connections? #4: Ludwig Nussel (lnussel) (2009-08-26 08:40:53) (reply to #3) Currently there's only org.freedesktop.network-manager-settings.system. modify, introduce something like org.freedesktop.network-manager- settings.user.modify so NM can determine whether it should accept user settings. #16: Wang Lance (lzwang) (2009-09-25 11:26:20) (reply to #4) Hi Ludwig Nussel I have added the following policy action: org.freedesktop.network-manager-settings.user.wired.apply org.freedesktop.network-manager-settings.user.wireless.apply org.freedesktop.network-manager-settings.user.mobile.apply org.freedesktop.network-manager-settings.user.vpn.apply org.freedesktop.network-manager-settings.user.dsl.apply . NM now can determine whether it should apply the user settings to devices by type. Does the implementation meet your request? I need your feedback to determine what should to do next step. Thanks, Lance Wang #17: Ludwig Nussel (lnussel) (2009-09-25 11:58:50) (reply to #16) Sure, that's even more than I had wished for. Would it be possible to also have a separate privilege for the connection sharing thingy? In contrast to the other configurations that one also messes with iptables and starts a DHCP daemon. #5: JP Rosevear (jproseve) (2009-08-26 17:06:51) (reply to #3) My suggestion would be to look at something like the following: org. freedesktop.network-manager-settings.system.modify org.freedesktop. network-manager-settings.system.add org.freedesktop.network-manager- settings.system.delete and the same for .user - you may even want to specifically allow or disallow adding for specific network types like wired, wireless, etc. You probably also want to have the ability to enable/disable wireless in general and enable/disable networking covered. You can default all of these to the current settings, but adding these would allow more lockdown opportunities. #6: Li Bin (binli) (2009-08-31 11:22:12) Well, We'll works on this feature in this week, know about the PolicyKit and NetworkManager, write the patch if time is okay. Tambet, Do you have any idea about this feature? #7: Luis Medinas (lmedinas) (2009-08-31 18:40:51) (reply to #6) Might worth looking at NM 0.8 (git master), it supports the latest polkit-1 and it should be released before 11.2. Maybe some of this features were introduced. #8: Tambet Ingo (tambet) (2009-09-01 09:40:05) (reply to #7) NM 0.8 will not be out before 11.2, it'll be out for the next Fedora release which will happen after 11.2. Also, current git master does not have any work for this feature, it's just been converted to use the newer, incompatible polkit API. #9: Tambet Ingo (tambet) (2009-09-01 09:43:56) (reply to #6) The upstream has been planning on having similar feature for a while now, but no work has been done on it yet. I strongly suggest to have a discussion with the upstream maintainer before any work gets done, otherwise our effort might end up thrown away as soon as upstream implements it. #10: Li Bin (binli) (2009-09-01 09:14:24) Yes, I talk with the upstream today, just wait for response. You can follow it from below link. Thanks! http://mail.gnome.org/archives/networkmanager-list/2009-September/date.html #11: Stephan Kulow (coolo) (2009-09-07 13:39:17) (reply to #10) didn't see a lot of replies. #12: Li Bin (binli) (2009-09-10 05:24:05) The upstream maintainer Dan already reply this issue, and it's no user case for seperating add, modify and delete permission, and the others was agreed. Lanc wang with me work the sled11 and upstream now, we'll provide a patch in this week. #13: Wang Lance (lzwang) (2009-09-15 08:10:43) Hi I add five policy like the following : org.freedesktop.network-manager- settings.system.wired.modify org.freedesktop.network-manager-settings. system.wireless.modify org.freedesktop.network-manager-settings.system. mobile.modify org.freedesktop.network-manager-settings.system.vpn. modify org.freedesktop.network-manager-settings.system.dsl.modify. As you know there will be one policy one type. I make a patch which works. But I feel a little confused on the user settings. As the user settings are saved in the gconf, so adding someting like manager- settings.user.*.modify make no sense. As far as I know user can always edit their gconf settings. I think what should be done may be the policy that determine if the users can apply their settings to the system devices throught dbus. Given we do it like that, should the nm-applet display the user setting in the menu, when a normal user can not apply his or her settings to system devices? I think it is better that nm-applet show both system settings and user settings, and it will show error dialog if a user try to apply user settings when the user does not have the right do that. Hi Tambet, what do you think? #14: Li Bin (binli) (2009-09-17 11:18:37) (reply to #13) Tambet reply in the mailinglist, we just lock the /system/networking path in gconf and the settings can't be changed. #15: Michael Meeks (michael_meeks) (2009-09-23 16:55:40) We should also add the case mentioned in bug #522742 - to allow disabling the "Create new wireless network" functionality. This is of particular concern to the security team, and I'd like to see it addressed as part of the same work if possible. Otherwise, this looks great - thanks Li Bin :-) #18: Li Bin (binli) (2009-09-25 12:03:28) (reply to #15) Michael, I've viewed the bug#522742, it talk more about sharing, and we don't need to disable "Create new wireless network", user can add it, but when they wanna to apply it by click the connection, check org. freedesktop.network-manager-settings.user.wireless.apply permission like the Lance describe in #16. Does it okay? #19: Michael Meeks (michael_meeks) (2009-09-28 10:10:26) (reply to #18) No - connecting to a new wireless network is -very- different from sharing all your existing connections over your current wireless network; I can see why people would want to allow one and not allow the other. We should (ideally) have a different policy setting for this - if possible. Thanks #25: Wang Lance (lzwang) (2009-10-28 11:49:58) (reply to #15) Hi Michael I have read bnc #522742. And it is about sharing network. I wonder that why only the "Create new wireless network" need a policy, since all kinds type connection can be shared. As far as I know in nm-applet 7.0 the "Create new wireless network" is only for adhoc wireless connection. Did you mean that sharing adhoc wireless connection have security problem? And other type connections do not ? Thanks, Lance Wang. #20: Tanja Roth (ta-ro) (2009-10-05 15:01:26) Can you please confirm what the final policy names (identifiers) are going to be for 11.2 and what can be influenced with them? (a short description as available from the Description field in polkit-gnome- authorization would be sufficient). I would like to mention this in the 11.2 docs about NetworkManager, but so far, I only found the one policy that relates to modifying administrator defined connections (org.freedesktop.network-manager- settings.system.modify). From your comments above I'm not sure if the names mentioned in #16 are the final ones for the newly added policies (and if the list is complete). Please advise asap as the translation deadline for this chapter is approaching. Thanks! #22: (binli) (2009-10-12 11:27:53) (reply to #20) Tanja, Just come back from holiday, sorry for late. Now this feature is still not in the upstream, I'm still working on it. I prepare to seperate the permission into more fined like, org.freedesktop.network-manager-settings.system.wireless.modify - Modify system wired connections org.freedesktop.network-manager-settings.system.wired.modify - Modify system wireless connections the description follow the policy. The #16 is now for the SLED 11-SP1 for temporary resolving usercase, I'm not sure if it could be received by upstream which is used for 11.2. So what's your translation deadline? I'll inform you when I confirm it with upstream. #23: (ta-ro) (2009-10-12 12:25:30) (reply to #22) Lin Bi, thanks very much for clarifying! :) Our localization deadline is Oct 15th but as the files have to go through language proofreading before, I have to finish the chapter today, I'm afraid. But don't worry, to be on the safe side (whatever the upstream decision may be), we can handle it as follows: for now, I'll only mention that there *are* policies for NetworkManager and where to find them in PolicyKit. We can then add more details for the next release of the docs (presumably SLE 11 SP1). #24: (ta-ro) (2009-10-12 13:18:21) (reply to #23) Removing the needinfo status. #26: Wang Lance (lzwang) (2009-11-02 08:51:11) Hi Ludwig Nussel Could you test this new functions in SLED11. I made the packages with the function. These are the URLs https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… I implemented the following policy: "org.freedesktop.network-manager-settings.system.wired.modify" "org. freedesktop.network-manager-settings.system.wireless.modify" "org. freedesktop.network-manager-settings.system.mobile.modify" "org. freedesktop.network-manager-settings.system.vpn.modify" "org. freedesktop.network-manager-settings.system.dsl.modify" "org.freedesktop.network-manager-settings.user.wired.apply" "org. freedesktop.network-manager-settings.user.wireless.apply" "org. freedesktop.network-manager-settings.user.mobile.apply" "org. freedesktop.network-manager-settings.user.vpn.apply" "org.freedesktop. network-manager-settings.user.dsl.apply" . And *.modify are the policy for the editing adding and deleting of the system connections. And *.apply are the policy for applying the user connection to activate the devices. You can see the default settings in /usr/share/PolicyKit/policy/org. freedesktop.network-manager-settings.system.policy, which make the NM behave like the one without those policy. Thanks, Lance Wang #27: Ludwig Nussel (lnussel) (2009-11-03 16:17:45) (reply to #26) I've tried it on openSUSE 11.1 now. Works great AFAICT. However I think the usability could be enhanced by creating system connections by default, at least when user connections are restricted. That way the user would not need to authenticate each time he wants to connect. wrt separate policy for shared connections, I think that should be doable by checking another condition in is_user_request_connection_type_authorized(), right? #28: Wang Lance (lzwang) (2009-11-06 10:52:31) (reply to #27) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1. Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2. Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager- settings.system.*.modify. 3. In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4. Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he have the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1. If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2. If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3. If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org. freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? #29: Wang Lance (lzwang) (2009-11-06 11:02:46) (reply to #27) (sorry. repeat reply for missing format) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1) Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2) Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager-settings.system.*. modify. 3) In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4) Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he has the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1) If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2) If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3) If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org.freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? #30: Ludwig Nussel (lnussel) (2009-11-06 11:09:33) (reply to #29) Ok. I already suspected that the system setting thing is hard to do with NM's architecture. Wrt share settings I'd set them to auth_admin_keep_always by default. However, the settings you add to the package get overwritten by polkit- default-privs anyways to be able to use different settings for 'standard' and 'restrictive'. #31: Wang Lance (lzwang) (2009-11-11 11:49:59) Hi Ludwig The version with shared connection is ready. These are https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… The policy added are org.freedesktop.network-manager-settings.user.*.apply- with-share. What should be mentioned is that the shared connection is only controlled by these. In other words org.freedesktop.network- manager-settings.user.*.apply do not control the shared connection. Thanks, Lance Wang -- openSUSE Feature: https://features.opensuse.org/305657

1 0