[opensuse-factory] samba-4.2.0-1.1.i586.rpm broken on oss 131
Samba packages at http://download.opensuse.org/repositories/network:/samba:/STABLE/openSUSE_13... do not work on opensuse 13.1. winbind and nmb give errors about being able to open /etc/samba/smb.conf even though the file exists and works fine with Samba 4.1. Samba packages from http://download.opensuse.org/repositories/network:/samba:/STABLE/openSUSE_13... work fine on opensuse 13.2. Is anyone else seeing the above problem with this Samba version on oss 13.1? Regards -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither libert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Freitag, 6. März 2015 schrieb Moby:
Samba packages at http://download.opensuse.org/repositories/network:/samba:/STABLE/openS USE_13.1/i586/ do not work on opensuse 13.1. winbind and nmb give errors about being able to open /etc/samba/smb.conf even though the file exists and works fine with Samba 4.1.
Samba packages from http://download.opensuse.org/repositories/network:/samba:/STABLE/openS USE_13.2/i586/ work fine on opensuse 13.2.
Is anyone else seeing the above problem with this Samba version on oss 13.1?
It seems samba 4.2 needs more permissions, which means you probably need to adjust your AppArmor profiles. See https://bugzilla.opensuse.org/show_bug.cgi?id=921098 for details. Please check your /var/log/audit/audit.log (if auditd is running) or /var/log/messages for AppArmor-related messages. (If you need help to update the profiles, just ask. Comment 3 on the bugreport also contains some quick hints how to do that.) I'll submit an updated AppArmor package to factory in some days (I wouldn't be surprised if the bugreport gets another "oh, and it also needs access to $file" ;-) I probably won't do an update for 13.1 only to support the combination 13.1 + latest samba, but nobody stops you from updating the profile yourself ;-) Regards, Christian Boltz -- Sometimes I feel that using osc (and OBS) is like driving an alien space ship, full of nice features, but I cannot read the manual ;-) [Filipe in opensuse-packaging] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Christian Boltz
I'll submit an updated AppArmor package to factory in some days (I wouldn't be surprised if the bugreport gets another "oh, and it also needs access to $file" ;-)
I probably won't do an update for 13.1 only to support the combination 13.1 + latest samba, but nobody stops you from updating the profile yourself ;-)
<aside> As 13.1 is designated as the next Evergreen, perhaps it would be good to continue updates there. </aside> -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Mar 07, 2015 at 08:04:43AM -0500, Patrick Shanahan wrote:
* Christian Boltz
[03-07-15 07:59]: [...] I'll submit an updated AppArmor package to factory in some days (I wouldn't be surprised if the bugreport gets another "oh, and it also needs access to $file" ;-)
I probably won't do an update for 13.1 only to support the combination 13.1 + latest samba, but nobody stops you from updating the profile yourself ;-)
<aside> As 13.1 is designated as the next Evergreen, perhaps it would be good to continue updates there. </aside>
With plain openSUSE 13.1 and 13.2 I expect we'll stay quite some time with Samba 4.1 But we all don't know how things develop in the next three or six months. I second Patrick that if possible and it doesn't cause too much hazle and work to adapt the required changes to AppArmor also to openSUSE 13.1 and 13.2. @Christian: Which type of help can the community offer you? Following your suggestions from the bug report to show which access permissions are required? Cheers, Lars
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Hello, Am Samstag, 7. März 2015 schrieb Lars Müller:
On Sat, Mar 07, 2015 at 08:04:43AM -0500, Patrick Shanahan wrote:
* Christian Boltz
[03-07-15 07:59]: [...] I'll submit an updated AppArmor package to factory in some days (I wouldn't be surprised if the bugreport gets another "oh, and it also needs access to $file" ;-)
I probably won't do an update for 13.1 only to support the combination 13.1 + latest samba, but nobody stops you from updating the profile yourself ;-)
<aside> As 13.1 is designated as the next Evergreen, perhaps it would be good to continue updates there. </aside>
Sorry if my statement wasn't clear enough ;-) All I said/meant is that I won't do an update because the profiles don't work with latest samba from an _extra repo_ (but I'll probably include it if I do an update for another reason). If something in the official 13.1 (update) repo needs a profile update, I'll of course deliver one ;-) and I also plan to do that in the Evergreen phase.
With plain openSUSE 13.1 and 13.2 I expect we'll stay quite some time with Samba 4.1
But we all don't know how things develop in the next three or six months.
In other words: I'll include the updated profile in the security:apparmor 2.8 and 2.9 packages (which I use as base for updates), and you notifiy me early enough if you decide to update to Samba 4.2 on 13.1 or 13.2 ;-)
I second Patrick that if possible and it doesn't cause too much hazle and work to adapt the required changes to AppArmor also to openSUSE 13.1 and 13.2.
@Christian: Which type of help can the community offer you? Following your suggestions from the bug report to show which access permissions are required?
Yes, detailed bugreports are always welcome - either with a profile patch or with the audit.log attached. I'm also happy about added profiles (in the respective package or submitted to the AppArmor package) - but the profile should work for (nearly) everybody. This unfortunately means that it's very hard to deliver profiles for programs that have a "save as..." feature ;-) (well, maybe we can collect them in an apparmor-profiles-paranoid package ;-) The most important point is to get feedback from people who actually use the AppArmor-protected programs, because those know best what is broken and also know some details, for example if allowing a specific file is enough or if a wildcard is the better choice. Speaking of that - I recently noticed that the klogd, syslogd and syslog-ng profiles aren't applied anymore because of the /usr move. Before I release an update with those profiles re-enabled (aka "path fixed"), I'd like to have them tested ;-) So if someone out there uses klogd, syslogd or syslog-ng and wants to test the updated profiles, please speak up ;-) (you'll also learn to read or at least grep audit.log because the changed profiles also uncovered a bug in aa-logprof [1] ;-) Regards, Christian Boltz PS: Ubuntu ships quite some additional profiles, but most of them are "hidden" in several packages, so it's hard to collect them. Fortunately debconf is very close to me this year (Heidelberg, Germany), and some of the upstream developers will be there too, so I hope for a solution to this problem. When collecting those profiles work, I'll probably package them in a separate package. [1] The problem looks easy - aa-logprof doesn't update profiles with a header line like profile foo /bar { because aa-logprof thinks the profile is named "foo /bar", but the log contains entries for "foo". Changing it to recognize only "foo" would be easy, but keeping the "/bar" is a bit ;-) harder. The result is that I wrote a series of ~20 patches that add tests to ensure I don't break anything, do some cleanup, fix some other bugs I noticed on the way [2] [3] and will finally add the handling for that style of profile headers ;-) [2] maybe you know that WTF moment when you write a test + expected result for existing code, and then see the _real_ result... [3] at least one of those bugs was quite entertaining ;-) - fortunately it happened only in very rare cases. -- Auf Windows 95 laufen so ziemlich alle Spiele. Für ernsthaftes Arbeiten sollte man aber zusätzlich ein Betriebssystem installieren. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/07/2015 05:10 PM, Christian Boltz wrote:
Hello,
Am Samstag, 7. März 2015 schrieb Lars Müller:
On Sat, Mar 07, 2015 at 08:04:43AM -0500, Patrick Shanahan wrote:
* Christian Boltz
[03-07-15 07:59]: [...] I'll submit an updated AppArmor package to factory in some days (I wouldn't be surprised if the bugreport gets another "oh, and it also needs access to $file" ;-)
I probably won't do an update for 13.1 only to support the combination 13.1 + latest samba, but nobody stops you from updating the profile yourself ;-) <aside> As 13.1 is designated as the next Evergreen, perhaps it would be good to continue updates there. </aside> Sorry if my statement wasn't clear enough ;-)
All I said/meant is that I won't do an update because the profiles don't work with latest samba from an _extra repo_ (but I'll probably include it if I do an update for another reason).
If something in the official 13.1 (update) repo needs a profile update, I'll of course deliver one ;-) and I also plan to do that in the Evergreen phase.
With plain openSUSE 13.1 and 13.2 I expect we'll stay quite some time with Samba 4.1
But we all don't know how things develop in the next three or six months. In other words: I'll include the updated profile in the security:apparmor 2.8 and 2.9 packages (which I use as base for updates), and you notifiy me early enough if you decide to update to Samba 4.2 on 13.1 or 13.2 ;-)
I second Patrick that if possible and it doesn't cause too much hazle and work to adapt the required changes to AppArmor also to openSUSE 13.1 and 13.2.
@Christian: Which type of help can the community offer you? Following your suggestions from the bug report to show which access permissions are required? Yes, detailed bugreports are always welcome - either with a profile patch or with the audit.log attached.
I'm also happy about added profiles (in the respective package or submitted to the AppArmor package) - but the profile should work for (nearly) everybody. This unfortunately means that it's very hard to deliver profiles for programs that have a "save as..." feature ;-) (well, maybe we can collect them in an apparmor-profiles-paranoid package ;-)
The most important point is to get feedback from people who actually use the AppArmor-protected programs, because those know best what is broken and also know some details, for example if allowing a specific file is enough or if a wildcard is the better choice.
Speaking of that - I recently noticed that the klogd, syslogd and syslog-ng profiles aren't applied anymore because of the /usr move. Before I release an update with those profiles re-enabled (aka "path fixed"), I'd like to have them tested ;-)
So if someone out there uses klogd, syslogd or syslog-ng and wants to test the updated profiles, please speak up ;-) (you'll also learn to read or at least grep audit.log because the changed profiles also uncovered a bug in aa-logprof [1] ;-)
Regards,
Christian Boltz
PS: Ubuntu ships quite some additional profiles, but most of them are "hidden" in several packages, so it's hard to collect them. Fortunately debconf is very close to me this year (Heidelberg, Germany), and some of the upstream developers will be there too, so I hope for a solution to this problem. When collecting those profiles work, I'll probably package them in a separate package.
[1] The problem looks easy - aa-logprof doesn't update profiles with a header line like profile foo /bar { because aa-logprof thinks the profile is named "foo /bar", but the log contains entries for "foo". Changing it to recognize only "foo" would be easy, but keeping the "/bar" is a bit ;-) harder. The result is that I wrote a series of ~20 patches that add tests to ensure I don't break anything, do some cleanup, fix some other bugs I noticed on the way [2] [3] and will finally add the handling for that style of profile headers ;-)
[2] maybe you know that WTF moment when you write a test + expected result for existing code, and then see the _real_ result...
[3] at least one of those bugs was quite entertaining ;-) - fortunately it happened only in very rare cases.
Would it be apparmor settings even if I am booting the machine with apparmor=0 on the kernel line in grub.cfg? From what I know my machine is not running apparmor (if apparmor is something that is run .. I am very unfamiliar with it and to the best of my knowledge do not use it!) -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hallo Leute, Am Sonntag, 8. März 2015 schrieb Moby:
Would it be apparmor settings even if I am booting the machine with apparmor=0 on the kernel line in grub.cfg? From what I know my
Yes, that should disable AppArmor on the kernel level. ("should" because I never tested it)
machine is not running apparmor (if apparmor is something that is run .. I am very unfamiliar with it and to the best of my knowledge do not use it!)
If still in doubt, ask rcapparmor status ;-) That said - is there any specific reason/problem why you want to disable AppArmor? Regards, Christian Boltz -- [Fontlinge] Glücklich wirst du damit nicht werden. Die Windowsversion konnte das, denn ich war jung und dumm, brauchte das Geld und dachte, man könne sich auf Standards verlassen. Die Sortierung nach PanoseID ergab dann das maximale Durcheinander. :-( [Ratti] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Christian Boltz
-
Lars Müller
-
Moby
-
Patrick Shanahan