November 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #300758, revision 96 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important - openSUSE-11.2: Done + openSUSE-11.2: Rejected by (jkupec) + reject date: 2009-11-30 14:20:26 + reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important - openSUSE-11.3: Done + openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) + #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) + There has been a misunderstanding here. What Thomas implemented is a + view of packages that no longer have update candidates (those which are + probably no longer maintained, thus 'orphaned'). + This very fate request (IMO) incorrectly uses the word 'orphaned' for + what is better described as "unused packages" or "no longer needed + packages", or "unnecessary packages". Definitely not orphans + (deborphan/rpmorphan is also a misfortunate name IMO). + Anyway, whether orphan or unused, this feature is not implemented yet, + thus i'm reopening it for 11.3. + #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) + reopening for 11.3 (see comment #25) + #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) + I suggest to call these packages unused instead of orphaned . I don't + want to decide this by myself, so please speak up. Here are my + arguments: + 1) the word 'orphan' describes something that has lost its parent(s). + In this case, it is actually the child that was lost - a package that + depended on other package has been removed. The parent package is still + installed, but there's no more use for it - it's unused . + 2) we (and a few other distros and communities as well) already use + orphaned to describe packages that are no longer cared for - + unmaintained packages, packages dropped from distros. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 305535] [webyast] Samba module
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Klaus Kämpf (kwk) Feature #305535, revision 24 Title: [webyast] Samba module openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-05 15:10:01 reject reason: Missing details. Priority Requester: Important - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: James McDonough (jmcdough) Partner organization: openSUSE.org Description: Original request stated in bugzilla: At the moment, it has to be decided if a user has an samba account can only be decided when the account is created. If an samba account shall be added later for a user, this is not possible with the Yast UsersPluginSamba, as this requires changing the password (or setting the same password again). IMHO, this restriction is to strict. The following should be possible: * Activate the samba account for the user : this should add the sambaSamAccount objectClass to the user, : at least set the user sid, optionally the group sid : leave the password empty * The user can then later on change/reset his password with "passwd" : The user has a valid posixAccount, which allows him to authenticate : himself against LDAP. : if there is an LDAP ACL "access to attrs=sambaNTPassword by self write", : the user is able to set his samba password even without an preexisting : samba password Additional comment from bugzilla The above described scenario is just one corner case where having no sambaNTPassword/sambaLMPassword could workout. Unfortunately: * Or samba configuration as created by YaST by default disallows write access to the samba*Password attributes, IIRC. * The user might be a pure Windows User, so he can't set his initial samba password using his Linux/Unix Account. References: https://bugzilla.novell.com/show_bug.cgi?id=444603 Business case (Partner benefit): openSUSE.org: Many customers report difficulties with various areas of samba yast administration, both with new features requested and layout of current ones. Discussion: #1: Christoph Thiel (cthiel1) (2009-05-28 15:34:16) James, do you have more details yet? Otherwise, we'll have to reject it for openSUSE 11.2 right away. #2: Wyatt Gosling (beachchairs) (2009-06-08 21:40:29) As someone who just spent a day configuring Samba, I support this. The Samba module is a bit advanced, but my main problem was I just didn't know I had to allow Samba in the firewall. I think the module should do something about this. Perhaps when you hit Ok you get a prompt allong the lines of "You have enabled Samba, but the Firewall is set to block Samba. Would you like to change the Firewall to allow Samba?" Still I would like to see a simpler module. Perhaps one that has a just a few options (then takes a reasonable stab at the rest). Maybe have a global "Enable Folder and Printer Sharing" toggle, and a toggle to enable password protection (and set the password!). Then have "Enable Printer Sharing", "Enable Folder Sharing" subcategories. I don't have any interest in printer sharing, so I don't know if any sub-options would be applicable or not. For folder sharing, you would need a list of directories to share. Not much else needs to be presented to the user IMO. Also have it so when you use the KDE Item Properties Panel (and the Gnome equivelent), it is pre-setup to allow users to add shares without root priveleges. #7: Ralph Ulrich (ulenrich) (2009-08-21 16:57:02) Would be great to see the module yast-samba as an input/substitute module for kde-systemsettings-advanced-samba #9: Klaus Kämpf (kwk) (2009-08-25 09:45:45) Out of scope for openSUSE 11.2 or SLE11 SP1. To be revisited for openSUSE 11.3 -- openSUSE Feature: https://features.opensuse.org/305535

1 0

[openFATE 305686] [beta1] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305686, revision 24 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… Thanks Lance Wang #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) He asked me directly... quoting: The feature I am working on need to change the default pam configration of +gnome-screensaver. In /etc/pam.d/gnome-screensaver the original settings are auth include common-auth account include common-account password include common-password session include common-session and the settings I changed to are auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so sha512 shadow nullok try_first_pass use_authok account include common-account password include common-password session include common-session #11: Marcus Meissner (msmeissn) (2009-11-30 10:12:49) (reply to #10) I do not think this will work. common-auth is there for a reason, namely you can switch authentication methods. YOu are overriding it to hard and fixed new method. also with fixed password crypt method. I do not see how this can change the timeout behaviour I also do not know if gnome-screensaver is able to do that anyway due to its simple method of chceking passwords. Ludwig or Thorsten , any comment? #12: Thorsten Kukuk (kukuk) (2009-11-30 11:23:21) (reply to #10) This settings doesn't make any sense and I fail to see why this changes do fix the issue. This changes can only fix the issue of the analysis of the problem is completly wrong. Expires is only checked in acct, so why does gnome-screensaver calles accounting at all? If gnome-screensaver should not check accounting, don't call that modules. If it should check accounting, the current behavior is exactly what you want. #13: Ludwig Nussel (lnussel) (2009-11-30 12:02:10) (reply to #12) Actually gnome-screensaver does not check accounting when using unix2_chkpwd as unix2_chkpwd doesn't check accounting. This can be seen when using a local user and expiring it's shadow info. I guess the eDir server actually locks the account or the pam module that authenticates with the eDir server gets it wrong. FWIW even if gnome-screensaver is compiled without unix2_chkpwd ie does the pam conversation itself and does call pam_acct_mgmt the expiry info gets lost. gnome-screensaver doesn't check the return value of pam_acct_mgmt... #14: Thorsten Kukuk (kukuk) (2009-11-30 12:05:42) (reply to #13) Ok, then my analysis is the following: - Problem only happens with novell-lum - gnome-screensaver, unix2_chkpwd and pam_unix2 do all ignore accounting => novell-lum checks accounting in auth phase, too. This is a novell- lum bug and should be handled via bugzilla, but nothing we can change on SLE* + #15: Thorsten Kukuk (kukuk) (2009-11-30 12:07:39) (reply to #14) + And this explains why the modified pam config file "fixes" the issue: + it removes novell-lum. Removing novell-lum from common-auth would have + the same effect. -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[openFATE 305686] [beta1] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305686, revision 23 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… Thanks Lance Wang #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) He asked me directly... quoting: The feature I am working on need to change the default pam configration of +gnome-screensaver. In /etc/pam.d/gnome-screensaver the original settings are auth include common-auth account include common-account password include common-password session include common-session and the settings I changed to are auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so sha512 shadow nullok try_first_pass use_authok account include common-account password include common-password session include common-session #11: Marcus Meissner (msmeissn) (2009-11-30 10:12:49) (reply to #10) I do not think this will work. common-auth is there for a reason, namely you can switch authentication methods. YOu are overriding it to hard and fixed new method. also with fixed password crypt method. I do not see how this can change the timeout behaviour I also do not know if gnome-screensaver is able to do that anyway due to its simple method of chceking passwords. Ludwig or Thorsten , any comment? #12: Thorsten Kukuk (kukuk) (2009-11-30 11:23:21) (reply to #10) This settings doesn't make any sense and I fail to see why this changes do fix the issue. This changes can only fix the issue of the analysis of the problem is completly wrong. Expires is only checked in acct, so why does gnome-screensaver calles accounting at all? If gnome-screensaver should not check accounting, don't call that modules. If it should check accounting, the current behavior is exactly what you want. #13: Ludwig Nussel (lnussel) (2009-11-30 12:02:10) (reply to #12) Actually gnome-screensaver does not check accounting when using unix2_chkpwd as unix2_chkpwd doesn't check accounting. This can be seen when using a local user and expiring it's shadow info. I guess the eDir server actually locks the account or the pam module that authenticates with the eDir server gets it wrong. FWIW even if gnome-screensaver is compiled without unix2_chkpwd ie does the pam conversation itself and does call pam_acct_mgmt the expiry info gets lost. gnome-screensaver doesn't check the return value of pam_acct_mgmt... + #14: Thorsten Kukuk (kukuk) (2009-11-30 12:05:42) (reply to #13) + Ok, then my analysis is the following: + - Problem only happens with novell-lum + - gnome-screensaver, unix2_chkpwd and pam_unix2 do all ignore + accounting + => novell-lum checks accounting in auth phase, too. This is a novell- + lum bug and should be handled via bugzilla, but nothing we can change + on SLE* -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[openFATE 305686] [beta1] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Ludwig Nussel (lnussel) Feature #305686, revision 22 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… Thanks Lance Wang #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) He asked me directly... quoting: The feature I am working on need to change the default pam configration of +gnome-screensaver. In /etc/pam.d/gnome-screensaver the original settings are auth include common-auth account include common-account password include common-password session include common-session and the settings I changed to are auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so sha512 shadow nullok try_first_pass use_authok account include common-account password include common-password session include common-session #11: Marcus Meissner (msmeissn) (2009-11-30 10:12:49) (reply to #10) I do not think this will work. common-auth is there for a reason, namely you can switch authentication methods. YOu are overriding it to hard and fixed new method. also with fixed password crypt method. I do not see how this can change the timeout behaviour I also do not know if gnome-screensaver is able to do that anyway due to its simple method of chceking passwords. Ludwig or Thorsten , any comment? #12: Thorsten Kukuk (kukuk) (2009-11-30 11:23:21) (reply to #10) This settings doesn't make any sense and I fail to see why this changes do fix the issue. This changes can only fix the issue of the analysis of the problem is completly wrong. Expires is only checked in acct, so why does gnome-screensaver calles accounting at all? If gnome-screensaver should not check accounting, don't call that modules. If it should check accounting, the current behavior is exactly what you want. + #13: Ludwig Nussel (lnussel) (2009-11-30 12:02:10) (reply to #12) + Actually gnome-screensaver does not check accounting when using + unix2_chkpwd as unix2_chkpwd doesn't check accounting. This can be seen + when using a local user and expiring it's shadow info. I guess the eDir + server actually locks the account or the pam module that authenticates + with the eDir server gets it wrong. + FWIW even if gnome-screensaver is compiled without unix2_chkpwd ie does + the pam conversation itself and does call pam_acct_mgmt the expiry info + gets lost. gnome-screensaver doesn't check the return value of + pam_acct_mgmt... -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[openFATE 305686] [beta1] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305686, revision 21 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… Thanks Lance Wang #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) He asked me directly... quoting: The feature I am working on need to change the default pam configration of +gnome-screensaver. In /etc/pam.d/gnome-screensaver the original settings are auth include common-auth account include common-account password include common-password session include common-session and the settings I changed to are auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so sha512 shadow nullok try_first_pass use_authok account include common-account password include common-password session include common-session #11: Marcus Meissner (msmeissn) (2009-11-30 10:12:49) (reply to #10) I do not think this will work. common-auth is there for a reason, namely you can switch authentication methods. YOu are overriding it to hard and fixed new method. also with fixed password crypt method. I do not see how this can change the timeout behaviour I also do not know if gnome-screensaver is able to do that anyway due to its simple method of chceking passwords. Ludwig or Thorsten , any comment? + #12: Thorsten Kukuk (kukuk) (2009-11-30 11:23:21) (reply to #10) + This settings doesn't make any sense and I fail to see why this changes + do fix the issue. + This changes can only fix the issue of the analysis of the problem is + completly wrong. + Expires is only checked in acct, so why does gnome-screensaver calles + accounting at all? + If gnome-screensaver should not check accounting, don't call that + modules. If it should check accounting, the current behavior is exactly + what you want. -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[openFATE 305686] [beta1] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Marcus Meissner (msmeissn) Feature #305686, revision 20 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… Thanks Lance Wang #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) He asked me directly... quoting: The feature I am working on need to change the default pam configration of +gnome-screensaver. In /etc/pam.d/gnome-screensaver the original settings are auth include common-auth account include common-account password include common-password session include common-session and the settings I changed to are auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so sha512 shadow nullok try_first_pass use_authok account include common-account password include common-password session include common-session + #11: Marcus Meissner (msmeissn) (2009-11-30 10:12:49) (reply to #10) + I do not think this will work. + common-auth is there for a reason, namely you can switch authentication + methods. YOu are overriding it to hard and fixed new method. also with + fixed password crypt method. + I do not see how this can change the timeout behaviour + I also do not know if gnome-screensaver is able to do that anyway due + to its simple method of chceking passwords. + Ludwig or Thorsten , any comment? -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[openFATE 305686] [beta1] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Marcus Meissner (msmeissn) Feature #305686, revision 18 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… Thanks Lance Wang + #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) + He asked me directly... quoting: + The feature I am working on need to change the default pam configration + of +gnome-screensaver. In /etc/pam.d/gnome-screensaver + the original settings are + auth include common-auth + account include common-account + password include common-password + session include common-session + and the settings I changed to are + auth required pam_env.so + auth optional pam_gnome_keyring.so + auth required pam_unix.so sha512 shadow nullok try_first_pass + use_authok + account include common-account + password include common-password + session include common-session -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[openFATE 301175] Update Messages Handling
by fate_noreply＠suse.de 30 Nov '09

30 Nov '09

Feature changed by: Karl Eichwalder (keichwa) Feature #301175, revision 50 Title: Update Messages Handling openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-11-23 08:29:21 reject reason: not done in time... Priority Requester: Mandatory Projectmanager: Important openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-08-07 11:17:55 reject reason: Solution needs to be integrated earlier in the release Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Andreas Jaeger (a_jaeger) Requested by: Marcus Meissner (msmeissn) Description: During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. In general, it is not possible to send emails from rpm install scripts. Most cases could be handled by the release notes but there are cases that cannot and we need a better solution to present this, especially since many people to not read the local emails. Relations: - update-messages functionality not implemented (novell/bugzilla/id: 450093) https://bugzilla.novell.com/show_bug.cgi?id=450093 - Software Management/Code11/Scripts and Messages (url: http://en.opensuse.org/Software_Management/Code11/Scripts_and_Messages#Auto…) Discussion: #2: Hendrik Vogelsang (hennevogel) (2006-09-05 14:52:12) Cleanup the messages and readd the features we lost with the removal of SUSEPlugger to zen-updater or whatever? #3: Duncan Mac-Vicar (dmacvicar) (2006-11-02 11:48:15) Current patches offer the message feature, so you could basically offer that package as a patch. If that is not sufficient, I propose something: We add a /var/spool/zypp-messages or something, and a binary which rpm spec call to inject messages. The zypp backend of the applet, check the spool in every check and use knotify to notifiy the user. I am only missing, where does the current rpm inject the messages to? #5: Edith Parzefall (emapedl) (2007-02-01 17:30:54) Andreas: any comments on the proposed solutions? #6: Duncan Mac-Vicar (dmacvicar) (2007-07-27 15:58:07) A proposal for normal packages: Create a dbus/dcop interface both applets implement. * create a /usr/sbin/update-messsage wrapper that allows rpms to send a message. * the wrapper sends a dcop/dbus message to the applets, which in turn show a passive popup? Other ideas? #7: Edith Parzefall (emapedl) (2007-08-06 13:50:22) Coolo, should we go ahead with the proposed solution and make a late feature admission request? #8: Stephan Kulow (coolo) (2007-08-06 19:18:17) (reply to #7) No, this requires documentation changes I'm not willing to accept. So I rather stay with the status quo ;( #9: Edith Parzefall (emapedl) (2007-08-07 11:05:55) Then please reject for 10.3. #10: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:19:05) Please reject for 11.0. All resources allocated with mandatory features already. #11: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:32:22) Please reject for SLE11/11.1. All resources allocated with mandatory features already. #12: Marcus Meissner (msmeissn) (2008-12-03 15:50:15) This was promised as "will be done" to the Maintenance Department. Mark it Mandatory for SP1. #13: Federico Lucifredi (flucifredi) (2009-01-23 15:39:07) (reply to #12) please note, any solution must not break "RPM only" compatibility - meaning these should be notification messages, not scripts used in any event to finish configuration or to cause "side effects" of any kind. #14: Federico Lucifredi (flucifredi) (2009-01-23 15:38:53) I disagree with the rationale that users don't read local mail. An admin should have that local mail forwarded, and I think we ought to facilitate configuring the forwarding even to other machines. I think that may have more success than popups... at least for Enterprise customers. For community use, sure, popups are helpful (as init 5 is more likely :-) #15: Stephan Kulow (coolo) (2009-03-04 11:35:25) (reply to #14) but who would send these mails if rpm is the only vehicle we can be sure of. We don't want packages to send mails. #16: Michael Andres (mlandres) (2009-09-23 17:18:17) That's the zypp.conf option I'd like to introduce for this feature: ## ## Command to be invoked to send update messages. ## ## Packages may leave an update message file in {update.messagesdir}. ## At the end of each commit, zypp collects those messages and may send ## a notification to the user. ## ## zypp will prepare the update messages according to the selected ## content format and pipe the content to the command. ## ## Format: ## single - For each update message invoke the command and send ## the message. ## none - For each update message invoke the command but don't ## use a pipe to send any data. You probably want to pass ## the message file on the commandline using %P (see ## Substitutions). ## digest - Single invocation of the command, sending the path ## names of all update message. One per line. ## bulk - Single invocation of the command, sending the ## concatenated content of all update messages, separated ## by Ctrl-L. ## ## Substitutions: ## %p - package identification (name-version-release.arch) ## %P - full path to the update message file ## ## Valid values: The value is specified as "format | command". ## An empty value will turn off any notification. ## ## Examples: single | mail -s 'Update message from %p' root ## none | my-send-script -f %P ## ## Default value: single | /usr/lib/zypp/notify-message -p %p ## # update.messages.notify = single | /usr/lib/zypp/notify-message -p %p #17: Michael Andres (mlandres) (2009-10-07 17:13:03) The libzypp part seems to be done with libzypp-6.18.0 (for openSUSE 11.2). The /usr/lib/zypp/notify-message script, which gets invoked per default, sends mail with subject [zypp-notify-message] packagename- version.arch to root. The feature can be configured/disabled in /etc/zypp.conf. The list of update message files is also returned via ZYppCommitResult, so zypper/UI could write a note, or even offer to display them if we want that too. And we could also think about sending the config file diffs we create via this feature. #19: Ján Kupec (jkupec) (2009-11-20 15:25:11) (reply to #17) Zypper 1.2.11 now shows a list of packages which wrote notifications, and offers to view them all in pager. Submitting the package in few minutes. #22: Christoph Thiel (cthiel1) (2009-11-27 15:07:38) (reply to #21) In that case, let's mark this feature as done, eh? :) + #23: Karl Eichwalder (keichwa) (2009-11-30 09:46:49) + A proper summary suitable for doc purposes is missing. We are not that + much interested in implementation details, but how the user will ssee + the implementation. + I guess this notification system will also for are package installation + time (not only in the update case)? + If the user updates the system (or just packages) using YaST, will YaST + display these notifications? Is this a one-time-opportunity, or is it + possible to display these messages later again? -- openSUSE Feature: https://features.opensuse.org/301175

1 0

[openFATE 305294] [beta1]Support Rotation hotkey in tablets (RANDR 1.2)
by fate_noreply＠suse.de 27 Nov '09

27 Nov '09

Feature changed by: Federico Mena Quintero (federico-mena) Feature #305294, revision 27 Title: [beta1]Support Rotation hotkey in tablets (RANDR 1.2) openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Federico Mena Quintero (federico-mena) Description: Tablet notebooks (especially the fancy new ones with Wacom pressure- sensitive screens) have a physical button to rotate the screen, in case you want to hold the tablet in portrait/landscape mode. We need to capture the XF86RotateWindows keysym, and rotate the laptop's display. + Relations: + - gnome-settings-daemon-fate305294-xf86rotatewindows.diff (url: http://www.gnome.org/~federico/misc/gnome-settings-daemon-fate305294-xf86ro…) Discussion: #1: Federico Mena Quintero (federico-mena) (2008-09-12 13:32:48) I just started a wiki page to track the status of support for laptops/tablets with these hotkeys: http://en.opensuse.org/Laptop_hotkeys_for_RANDR #2: Stefan Dirsch (sndirsch) (2009-04-15 17:16:00) Don't know how I can help here. #3: Stefan Dirsch (sndirsch) (2009-06-06 12:36:15) This is more for the RANDR >= 1.2 tool developers I would say. #5: Federico Mena Quintero (federico-mena) (2009-09-02 20:26:09) I'll take care of this. #6: Klaas Freitag (kfreitag) (2009-09-02 21:01:09) Great, thanks. Assuming you do it for both SLE and openSUSE I set it to implementation for both platforms. -- openSUSE Feature: https://features.opensuse.org/305294

1 0