[opensuse-factory] 12.1 is around the corner, and I must make my concerns known.
To the Green Blooded, The excitement is building as yet another release of our beloved openSUSE is just around the corner. This coming release looks as though it may be yet more exciting than 11.4 was; 11.4 being the distro I run only and place my clients on as well. Last release was a bit rough around the edges at launch, and had issues that shook confidence of new users. Though it brought enormous improvements in speed and stability, I must still worry about the first experience. As you most likely will recall, there were several discrepancies and throwbacks to previous versions that sullied 11.4 upon release. Primarily ones I noticed were the oddity of the DVD using the old Knetwork Manager as opposed to the current plasmoid version that was present in the KDE Live CD version. There was also the matter of the pre 11 series behavior of AppArmor in blocking Samba; this I found was more pronounced in the DVD install. (To this day I can't get Samba to work properly in a DVD install.) Since I am not a developer, and have only a brief familiarity with many of the logistical issues facing a project of this magnitude I will not offer an immediate critique. However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed. 11.4 was a grand milestone, creating enormous buzz with its massive improvements. 11.4 launched openSUSE to a new height of interest and popularity, and with that in consideration we must be careful to not put off the new users. Further, openSUSE has long been known as the flagship for KDE and as such many people will be looking to us for an alternative to the much disliked Gnome3 and Unity. Sincerely, Roger openSUSE Ambassador P.S. In this section I wanted to raise some questions, critiques, and a small wishlist. As this is less important by far I have placed it where it is. The odd discrepancies in the DVD vs LiveCD version leads me to wonder where there was some sort of disconnect between teams. I further wonder why there was not a central unified repository for the two versions, as I imagine that would have helped remove discrepancies. Why did this occur and how can it be prevented? Though I know its late in the game to make a lot of changes to the final product, this is my personal wishlist of things to see in future openSUSE (Gnome team disregard KDE specific things): 1. Have a simple default configuration for Samba, like in Ubuntu where it simply works out of the box. a. Fix AppArmor so it isn't battling with Samba constantly. 2. AppArmor desktop notifier. It would be nice for the user to know when AppArmor blocks something, and be able to click straight through to the Profile Update wizard. But even somethin as simple as a system announcement would be superior and be picked up by the KDE notification system. 3. Maintain more current versions of some neglected packages, especially WINE. Rekonq being the other package I would have liked to see updated. 4. Amarok is known as one of the most feature rich players in all of Linux. However, it often suffers from bugs that crash it constantly, or degrade its performance. Also its interface suffers from not using common conventions, and thus confounds new users. I recommend replacing it with Clementine as it is more stable and has a friendlier interface, and is yet KDE native. 5: There has been some talk about replacing the YaST Printer module with a KDE one in userspace. Frankly I think this is a terrible idea as YaST is the only tool on any platform that has actually made configuration of the god-forsaken yet popular HP AllInOne devices simple. Thank you for your time and consideration. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 15.08.2011 21:20, schrieb Roger Luedecke:
However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed.
Sorry, I don´t get it. Where we are loosing users? And why? And the releasing point of 12.1 is actually the right choose. If we release it later, there won´t be time enough between KDE 4.7 and 4.8. So, could you please explain the quoted post to me? thanks a lot, -- Kim Leyendecker (kdl@k-dl.de.vu) openSUSE Ambassador, openSUSE Wiki Team DE HAVE A LOT OF FUN! http://www.opensuse.org Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute or create your own Linux distro. Give SUSE Studio a try. http://www.susestudio.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 15 August 2011 16:16, Kim Leyendecker
wrote: Am 15.08.2011 21:20, schrieb Roger Luedecke: However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed.
Sorry, I don´t get it. Where we are loosing users? And why?
And the releasing point of 12.1 is actually the right choose. If we release it later, there won´t be time enough between KDE 4.7 and 4.8.
So, could you please explain the quoted post to me?
I think Roger (generally) means that there needs to be more fine tuning before releases. At least in this sense, I agree. It's why I'm doing more testing myself. One simple solution to this is to make milestone release more prominent. Like posting an something like an advertisment on opensuse.org. I don't think pushing back a release is necessarily a good thing because people expect and prepare for a release on a certain date.
thanks a lot,
-- Kim Leyendecker (kdl@k-dl.de.vu) openSUSE Ambassador, openSUSE Wiki Team DE HAVE A LOT OF FUN! http://www.opensuse.org Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute or create your own Linux distro. Give SUSE Studio a try. http://www.susestudio.com
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday, August 15, 2011 03:00:55 PM you wrote:
On 15 August 2011 16:16, Kim Leyendecker
wrote: Am 15.08.2011 21:20, schrieb Roger Luedecke: However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed.
Sorry, I don´t get it. Where we are loosing users? And why?
And the releasing point of 12.1 is actually the right choose. If we release it later, there won´t be time enough between KDE 4.7 and 4.8.
So, could you please explain the quoted post to me?
I think Roger (generally) means that there needs to be more fine tuning before releases. At least in this sense, I agree. It's why I'm doing more testing myself. One simple solution to this is to make milestone release more prominent. Like posting an something like an advertisment on opensuse.org.
I don't think pushing back a release is necessarily a good thing because people expect and prepare for a release on a certain date.
thanks a lot,
-- Kim Leyendecker (kdl@k-dl.de.vu) openSUSE Ambassador, openSUSE Wiki Team DE HAVE A LOT OF FUN! http://www.opensuse.org Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute or create your own Linux distro. Give SUSE Studio a try. http://www.susestudio.com
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org Exactly, that is precisely what I mean. And though 11.4 definately got patched up really nice, I wasn't thrilled for months and only kept it on my Netbook because despite the glitches it was faster. Much to my chagrin, it also meant I had to switch clients to Ubuntu instead of openSUSE as I would normally do for Win2Lin conversions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 00:00, Steven Sroka a écrit :
One simple solution to this is to make milestone release more prominent. Like posting an something like an advertisment on opensuse.org.
the best solution, IMHO i to *use* the new distro. 12.1 is quite usable from the beginning, having much less stoppers than previous ones, due mostly to the automatic testbed. jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 16/08/11 16:28, jdd wrote:
Le 16/08/2011 00:00, Steven Sroka a écrit :
One simple solution to this is to make milestone release more prominent. Like posting an something like an advertisment on opensuse.org.
the best solution, IMHO i to *use* the new distro. 12.1 is quite usable from the beginning, having much less stoppers than previous ones, due mostly to the automatic testbed.
jdd
I will use 12.1 when it is released and, if I like it, I will tell........whoever may read the opensuse help list. I will more than likely also discuss it with some of my friends who already use openSUSE. WOW! Now *THAT'S* spreading the word, ain't it?! :-) . Which is why, of course, corporations spend millions of $ in advertising (and for which 'you' pay!) their products to attract suckers to buy their products :-) . But openSUSE is different: simply using it - because it has "less stoppers" and without knowing that it even exists - is enough to change the world. But, then, what do I know? :-( . BC -- "Oh what a tangled web we weave When first we practice to deceive." Sir Walter Scott -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 16.08.2011 08:58, schrieb Basil Chupin:
I will use 12.1 when it is released and, if I like it, I will tell........whoever may read the opensuse help list.
I will more than likely also discuss it with some of my friends who already use openSUSE.
WOW! Now *THAT'S* spreading the word, ain't it?! :-) .
Yeah! right way, my friend.
Which is why, of course, corporations spend millions of $ in advertising (and for which 'you' pay!) their products to attract suckers to buy their products :-) .
But openSUSE is different: simply using it - because it has "less stoppers" and without knowing that it even exists - is enough to change the world.
But at the same way we need some of these advertisements because the mass crowd (not the technical side) doesn´t about openSUSE, because they simply don´t care what´s on their PC, they just want to work with it. We have to reach this people too, so, advertising isn´t the wrong way at all. -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 16.08.2011 08:28, schrieb jdd:
the best solution, IMHO i to *use* the new distro. 12.1 is quite usable from the beginning, having much less stoppers than previous ones, due mostly to the automatic testbed.
+1 I´ve got Milestone 3 running on a virtual machine and for basic computing it´s real okay. I don´t know how M4 will be, but if it will be like M3, I have no concerns about that not-savvy people get problems with it. thanks -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 16.08.2011 08:28, schrieb jdd:
the best solution, IMHO i to *use* the new distro. 12.1 is quite usable from the beginning, having much less stoppers than previous ones, due mostly to the automatic testbed.
+1
I´ve got Milestone 3 running on a virtual machine and for basic computing it´s real okay. I don´t know how M4 will be, but if it will be like M3, I have no concerns about that not-savvy people get problems with it.
thanks Side note. I would like to help with testing, but don't understand virtualization on Linux. If someone could walk me through over private e-mail
On Tuesday, August 16, 2011 01:22:00 AM Kim Leyendecker wrote: that would be great. I would install outright, except that I need my computers functional. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 15:36, Roger Luedecke a écrit :
Side note. I would like to help with testing, but don't understand virtualization on Linux. If someone could walk me through over private e-mail that would be great. I would install outright, except that I need my computers functional.
best way is multi-boot. What we need the most to test is the hardware and there the virtualisation don't help :-) jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/16/2011 09:02 AM, jdd wrote:
Le 16/08/2011 15:36, Roger Luedecke a écrit :
Side note. I would like to help with testing, but don't understand virtualization on Linux. If someone could walk me through over private e-mail that would be great. I would install outright, except that I need my computers functional.
best way is multi-boot. What we need the most to test is the hardware and there the virtualisation don't help :-)
I don't believe that to be true. Although real hardware is needed to test some bugs, a lot of them can be tested on the virtualized hardware. My conclusion is that both kinds of tests are needed. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 16.08.2011 17:55, schrieb Larry Finger:
On 08/16/2011 09:02 AM, jdd wrote:
Le 16/08/2011 15:36, Roger Luedecke a écrit :
Side note. I would like to help with testing, but don't understand virtualization on Linux. If someone could walk me through over private e-mail that would be great. I would install outright, except that I need my computers functional.
best way is multi-boot. What we need the most to test is the hardware and there the virtualisation don't help :-)
I don't believe that to be true. Although real hardware is needed to test some bugs, a lot of them can be tested on the virtualized hardware. My conclusion is that both kinds of tests are needed.
I love testing new systems on virtual machines, because I can create a low end machine and test the performance. IMHO, that´s very important to the system, because we don´t need any tests on high-end machines (okay, we need, but not so many like on low-end) but on low end machines because *only* with that way, we can promise our users that our system works on their machines, no matter how low-level they are. thanks -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 18:40, Kim Leyendecker a écrit :
I love testing new systems on virtual machines,
yes, me too. But it's too easy! that said any distro *have to* work on virtual machine, because it's the way we can do demos :-) but when I try to install on real hardware and fail, the result for the public is pretty bad :-( jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 16.08.2011 19:23, schrieb jdd:
yes, me too. But it's too easy! that said any distro *have to* work on virtual machine, because it's the way we can do demos :-)
And it´s a good way to simulate low-end hardware (you can create a 8GB harddrive, and use 1GB RAM. I did it with Ubuntu 9.10 a year ago.)
but when I try to install on real hardware and fail, the result for the public is pretty bad :-(
Of course it´s bad. And of course we have to test on *real* hardware too ;-) -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 19:50, Kim Leyendecker a écrit :
And it´s a good way to simulate low-end hardware (you can create a 8GB harddrive, and use 1GB RAM. I did it with Ubuntu 9.10 a year ago.)
yes, but you can also do this on real hardware. Making a small partition is easy, you can disable in the kernel the multiprocessing and there is an utility (I forgot the name) to limit the ram used not to say I don't love virtualbox :-)) jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 16.08.2011 20:58, schrieb jdd:
yes, but you can also do this on real hardware. Making a small partition is easy, you can disable in the kernel the multiprocessing and there is an utility (I forgot the name) to limit the ram used
Of course you can, but how when you haven´t any old hardware around? ;-) -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 21:11, Kim Leyendecker a écrit :
Am 16.08.2011 20:58, schrieb jdd:
yes, but you can also do this on real hardware. Making a small partition is easy, you can disable in the kernel the multiprocessing and there is an utility (I forgot the name) to limit the ram used
Of course you can, but how when you haven´t any old hardware around? ;-)
read the post: you can do on any new hardware jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
` jdd wrote:
Le 16/08/2011 00:00, Steven Sroka a écrit :
One simple solution to this is to make milestone release more prominent. Like posting an something like an advertisment on opensuse.org.
the best solution, IMHO i to *use* the new distro. 12.1 is quite usable from the beginning, having much less stoppers than previous ones, due mostly to the automatic testbed.
jdd
I upgraded to 11.4, last April. I have yet to 'complete' the upgrade...due to various packages compatibility problems (samba taking the longest, but SO many packages just 'hosed' my configs -- and it was very ugly...worst upgrade ever. and I've been doing them since 6.x. It isn't just about bugs...even bash was upgraded w/incompatible features/changes. Certainly much of this isn't fault of opensuse, but seems like a general decline in caring about SW compat and reliability... that O.S. inherits much of by virtue of having a large package base. Getting this 'fixed' is a slow & hard process, as no one cares about your problems as much as you do! ;-) So jumping on the lastest SW packages just because they don't crash doesn't say diddly about whether or not my server will still being doing all it's supposed to do for my PC...(their married...server has almost no 'face' ( -- has a text interface but no gui at the console). Never got X to work there and not sure it's worth it given how little I do @ that system's console. And Win machine has almost no body -- (physical storage)...has a brains and pretty face, but needs the server to actually for everything (internet, email, the works). And server would feel ignored as who really wants to use a text console? Upshot of that -- I use and require high integration when my server is down due to an upgrade, everything is disabled. And man, when you try to run a home domain -- when things break, .. well, not good. So I would second a motion for people to take a few more deep breaths before jumping ahead to the latest and greatest incompatible update. I mean, I would **like** to be doing things with my free time, other than just maintaining my home Network... (selfish me!, but I'd like to get back to doing scans (astara @(minitokyo/animepaper)) and spend alot more time *using the computers* rather than maintain them). :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 20/08/2011 10:43, Linda Walsh a écrit :
And server would feel ignored as who really wants to use a text console?
? I only use console for my online server and of course *never* the factory version I use factory for my dayly use (net, text processing)
jumping ahead to the latest and greatest incompatible update.
you should use SLES with 7 years care jdd -- http://www.dodin.net http://www.dailymotion.com/video/xgxog7_clip-l-ombre-et-la-lumiere-3-bad-pig... http://www.youtube.com/watch?v=FGgv_ZFtV14 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 20/08/11 10:28, jdd wrote:
Le 20/08/2011 10:43, Linda Walsh a écrit :
And server would feel ignored as who really wants to use a text console?
? I only use console for my online server and of course *never* the factory version
I use factory for my dayly use (net, text processing)
jumping ahead to the latest and greatest incompatible update.
you should use SLES with 7 years care
jdd
I've always used bleeding edged even at work where I needed 24/7 fully functionality. Except for the upgrade to Milestone 1 where I had to sculpt a workaround to get a desktop running on one box, SuSE 6.x right up to 12.1 Milestone 3 have been solid. I run lots of 3rd party software that's at the heart of what I do daily and I find that the incremental changes are no problem - zypper dup is done many times weekly. Linux has always introduced and discarded packages, kernels undergo significant changes, 32-bit to 64-bit, hardware upgrades have joined in the mix but 6 boxes with different hardware just carry on solidly working whatever I throw at them. Over quite some time I've seen the number of bugs to the list decrease markedly and I mostly see posts about what should go into the next release. If there is some dastardly plot to make my boxes unworkable, openSUSE has so far failed. Linus said "Be Happy" and I am happy. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 20 Aug 2011 16:17:46 +0530, Sid Boyce
I've always used bleeding edged even at work where I needed 24/7 fully functionality. Except for the upgrade to Milestone 1 where I had to sculpt a workaround to get a desktop running on one box...
i'm doing the same, mostly, and am happy with it. if there isn't anything to fix or figure out in a long while i actually get bored. but that isn't applicable to everyone. particularly people who tend to complain when things don't work as they are supposed to should stick to stable or long time support versions. (as far as i remember, you don't all into that category.) -- phani. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 20/08/11 11:59, phanisvara das wrote:
On Sat, 20 Aug 2011 16:17:46 +0530, Sid Boyce
wrote: I've always used bleeding edged even at work where I needed 24/7 fully functionality. Except for the upgrade to Milestone 1 where I had to sculpt a workaround to get a desktop running on one box...
i'm doing the same, mostly, and am happy with it. if there isn't anything to fix or figure out in a long while i actually get bored. but that isn't applicable to everyone. particularly people who tend to complain when things don't work as they are supposed to should stick to stable or long time support versions. (as far as i remember, you don't all into that category.)
Wise words - stick to a stable version that works for the main workhorse and use a second box for testing before deploying a new version on the main box and then complaining. What I try to tell some guys who complain that this or that in a lowly Milestone doesn't work, shut up and file a bug. Someone has to ignore the warning label so the developers get their work widely tested and validated and that's the likes of us. I test and run the latest Milestone, vanilla kernels, NVidia drivers, VirtualBox, etc. so that I can report back problems and get them fixed well before the distro goes GM and then goes tits up for a lot of users who would justifiably lose all sense of humour. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Aug 15, 2011 at 6:00 PM, Steven Sroka
On 15 August 2011 16:16, Kim Leyendecker
wrote: Am 15.08.2011 21:20, schrieb Roger Luedecke: However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed.
Sorry, I don´t get it. Where we are loosing users? And why?
And the releasing point of 12.1 is actually the right choose. If we release it later, there won´t be time enough between KDE 4.7 and 4.8.
So, could you please explain the quoted post to me?
I think Roger (generally) means that there needs to be more fine tuning before releases. At least in this sense, I agree. It's why I'm doing more testing myself. One simple solution to this is to make milestone release more prominent. Like posting an something like an advertisment on opensuse.org.
I don't think pushing back a release is necessarily a good thing because people expect and prepare for a release on a certain date.
My impression is Tumbleweed is actually acting as a significant test vehicle for factory. If true, 12.1 should be a great release since so much of the core technology has been getting tested in Tumbleweed. The kernel in particular hits Tumbleweed at almost the same time it hits factory (or even earlier sometimes.) Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Aug 16, 2011 at 02:04:16PM -0400, Greg Freemyer wrote:
On Mon, Aug 15, 2011 at 6:00 PM, Steven Sroka
wrote: On 15 August 2011 16:16, Kim Leyendecker
wrote: Am 15.08.2011 21:20, schrieb Roger Luedecke: However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed.
Sorry, I don´t get it. Where we are loosing users? And why?
And the releasing point of 12.1 is actually the right choose. If we release it later, there won´t be time enough between KDE 4.7 and 4.8.
So, could you please explain the quoted post to me?
I think Roger (generally) means that there needs to be more fine tuning before releases. At least in this sense, I agree. It's why I'm doing more testing myself. One simple solution to this is to make milestone release more prominent. Like posting an something like an advertisment on opensuse.org.
I don't think pushing back a release is necessarily a good thing because people expect and prepare for a release on a certain date.
My impression is Tumbleweed is actually acting as a significant test vehicle for factory.
If true, 12.1 should be a great release since so much of the core technology has been getting tested in Tumbleweed.
The kernel in particular hits Tumbleweed at almost the same time it hits factory (or even earlier sometimes.)
There are only a very small subset of packages in Tumbleweed compared to Factory, so the comparison isn't fair at all, sorry. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/16/2011 02:09 PM, Greg KH wrote:
On Tue, Aug 16, 2011 at 02:04:16PM -0400, Greg Freemyer wrote:
On Mon, Aug 15, 2011 at 6:00 PM, Steven Sroka
wrote: On 15 August 2011 16:16, Kim Leyendecker
wrote: Am 15.08.2011 21:20, schrieb Roger Luedecke: However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed.
Sorry, I don´t get it. Where we are loosing users? And why?
And the releasing point of 12.1 is actually the right choose. If we release it later, there won´t be time enough between KDE 4.7 and 4.8.
So, could you please explain the quoted post to me?
I think Roger (generally) means that there needs to be more fine tuning before releases. At least in this sense, I agree. It's why I'm doing more testing myself. One simple solution to this is to make milestone release more prominent. Like posting an something like an advertisment on opensuse.org.
I don't think pushing back a release is necessarily a good thing because people expect and prepare for a release on a certain date.
My impression is Tumbleweed is actually acting as a significant test vehicle for factory.
If true, 12.1 should be a great release since so much of the core technology has been getting tested in Tumbleweed.
The kernel in particular hits Tumbleweed at almost the same time it hits factory (or even earlier sometimes.)
There are only a very small subset of packages in Tumbleweed compared to Factory, so the comparison isn't fair at all, sorry.
thanks,
greg k-h Choosing openSUSE Tumbleweed is an alternate option for serious users compared to upgrading to openSUSE 12.1.
Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 20:23, Roman Bysh a écrit :
Choosing openSUSE Tumbleweed is an alternate option for serious users compared to upgrading to openSUSE 12.1.
if I understand well TW, it will switch to 12.1 as soon as 12.1 is released (or nearly). in that sense it's not a completely rolling release, you have at some time to change main repo if I didn't understand, greg KH will correct me :-) jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Aug 16, 2011 at 09:03:52PM +0200, jdd wrote:
Le 16/08/2011 20:23, Roman Bysh a écrit :
Choosing openSUSE Tumbleweed is an alternate option for serious users compared to upgrading to openSUSE 12.1.
if I understand well TW, it will switch to 12.1 as soon as 12.1 is released (or nearly).
in that sense it's not a completely rolling release, you have at some time to change main repo
if I didn't understand, greg KH will correct me :-)
No correction needed, you are exactly correct :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/16/2011 03:03 PM, jdd wrote:
Le 16/08/2011 20:23, Roman Bysh a écrit :
Choosing openSUSE Tumbleweed is an alternate option for serious users compared to upgrading to openSUSE 12.1.
if I understand well TW, it will switch to 12.1 as soon as 12.1 is released (or nearly).
in that sense it's not a completely rolling release, you have at some time to change main repo
if I didn't understand, greg KH will correct me :-)
jdd This is the beauty of using Tumbleweed. We get to try newest yet stable software with the latest version.
I like it a lot. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 16.08.2011 20:04, schrieb Greg Freemyer:
My impression is Tumbleweed is actually acting as a significant test vehicle for factory.
If true, 12.1 should be a great release since so much of the core technology has been getting tested in Tumbleweed.
The kernel in particular hits Tumbleweed at almost the same time it hits factory (or even earlier sometimes.)
Well, I also think that 12.1 becomes a very good release from the technical side. The Marketing side is another story... -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 15 12:20 Roger Luedecke wrote (excerpt):
There has been some talk about replacing the YaST Printer module with a KDE one in userspace. Frankly I think this is a terrible idea as YaST is the only tool on any platform that has actually made configuration of the god-forsaken yet popular HP AllInOne devices simple.
Unless you contribute to the matching FATE request, your contribution is probably lost. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday, August 16, 2011 12:17:19 AM Johannes Meixner wrote:
Hello,
On Aug 15 12:20 Roger Luedecke wrote (excerpt):
There has been some talk about replacing the YaST Printer module with a KDE one in userspace. Frankly I think this is a terrible idea as YaST is the only tool on any platform that has actually made configuration of the god-forsaken yet popular HP AllInOne devices simple.
Unless you contribute to the matching FATE request, your contribution is probably lost.
Kind Regards Johannes Meixner Quite frankly, I think FATE needs a major facelift to actually be more useful. And frankly it looks like FATE is almost entirely ignored. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 16 09:17 Johannes Meixner wrote (excerpt):
Unless you contribute to the matching FATE request, your contribution is probably lost.
The matching FATE request https://features.opensuse.org/308045 has a misleading title "Switch to native printer config". Obviously "the two and only native printer configs" are the CUPS web interface and the CUPS command line tools. For KDE users the meaning of "native" is of course different. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
1. Have a simple default configuration for Samba, like in Ubuntu where it simply works out of the box. a. Fix AppArmor so it isn't battling with Samba constantly.
2. AppArmor desktop notifier. It would be nice for the user to know when AppArmor blocks something, and be able to click straight through to the Profile Update wizard. But even somethin as simple as a system announcement would be superior and be picked up by the KDE notification system.
While the idea behind AppArmor is good, the whole concept dies without maintenance. Ideally, upstream projects would care for AppArmor profiles (as much as they would care for SELinux), or if not, beloved packagers would spend their precious time maintaing AppArmor profiles for each of the many thousands of packages that are currently in Factory. Reality hits hard in that case, we have around 10 services that have really working, up-to-date AppArmor profiles. The other profiles we ship come from Ubuntu and do not necessarily match or packages. The packages with the most security issues have none (like Firefox, Flash player, Adobe Reader). The question is, why do we force this onto (primarily) desktop users by default? I'm sure, the seasoned admins using openSUSE will cry out loud, how we could actually think about such a move. But really, we should either don't enable AppArmor and/or don't even install the packages by default. It just doesn't make any sense. For most users, the AppArmor experience only involves silently failing applications, as we lack desktop integration (as you mentioned). And it's one of those daemons (together with auditd) that are usually removed first on any fresh installation. Everyone that would complain about such a move is invited to fix the profiles we have or even create _and maintain_ new ones. Otherwise I proposing a grace period for people to step up and get rid of this for 12.1. However, the situation is completely different on SLE, but that's not to be discussed here, please. -- Mit freundlichen Grüßen, Sascha Peilicke
Le 16/08/2011 10:55, Sascha Peilicke a écrit :
For most users, the AppArmor experience only involves silently failing applications, as we lack desktop integration (as you mentioned). And it's one
I think most user have never any problme with apparmor; In fact I never had any jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 16.8.2011 13:50, jdd napsal(a):
Le 16/08/2011 10:55, Sascha Peilicke a écrit :
For most users, the AppArmor experience only involves silently failing applications, as we lack desktop integration (as you mentioned). And it's one
I think most user have never any problme with apparmor; In fact I never
That's like stating that "most users don't use Firefox". Which is true as number of users of Firefox is below 50%. If AppArmor works, it's all fine, but when it stops working for you, it's not ... a.) easy to find out that caused by AppArmor ("most users" won't know) b.) easy to fix Just my opinion Bye Lukas - -- Lukas Ocilka, Appliances Department, SUSE LINUX s.r.o. MD: Jeff Hawn, Jennifer Guild, Alena Hendrichova -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFOSlrfVSqMdRCqTiwRAuCBAJ9KHhsfI/sjfqu61JbY6eeR5GKf9QCZARXG hcnyL7AWz63PieVa4Wax/+0= =0bsh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 13:56, Lukas Ocilka a écrit :
If AppArmor works, it's all fine, but when it stops working for you, it's not ...
well, if it stop working only for you, it's a bug that have to be fixed, no? curiously enough, this was at a moment a Novell/opensuse app and is now Ubuntu (according to wikipedia) just tested, I don't see many apparmor related threads in the opensuse forums that could show high problems that said as apparmor is a silent application I don't know if it's usefull at all :-) jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday, August 16, 2011 07:00:58 AM jdd wrote:
that said as apparmor is a silent application I don't know if it's usefull at all Good point. I say we remove it from default. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 16.08.2011 17:03, schrieb Roger Luedecke:
Good point. I say we remove it from default.
If so, please open an request @features.o.o thanks -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 16 August 2011 17:48:24 Kim Leyendecker wrote:
Am 16.08.2011 17:03, schrieb Roger Luedecke:
Good point. I say we remove it from default.
If so, please open an request @features.o.o
thanks And let it bitrot. In the meantime, I cloned 'openSUSE/patterns' on gitorious, removed it from the defaults and did a merge request. Way more effective -- Mit freundlichen Grüßen, Sascha Peilicke
On Tue, 16 Aug 2011 20:33:16 +0530, Roger Luedecke
On Tuesday, August 16, 2011 07:00:58 AM jdd wrote:
that said as apparmor is a silent application I don't know if it's usefull at all
Good point. I say we remove it from default.
+1 i don't think it's needed in a desktop environment. should be available through zypper/YAST, perhaps as a profile, together with anti-virus stuff, that also has it's uses (when serving windows machines). would have to be mentioned in prominent places, specially related to server software, for those who actually use it and may not like a surprise like finding it silently dropped from their default installation. -- phani. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Roger Luedecke wrote:
On Tuesday, August 16, 2011 07:00:58 AM jdd wrote:
that said as apparmor is a silent application I don't know if it's usefull at all
Good point. I say we remove it from default.
If apparmor causes a problem, you'll know anyway - if it prevents unauthorized access, you don't _really_ need to know, but otherwise you would just do a regular review of the logfile. (is there any SNMP support for apparmor?) In my experience, apparmor causes no problems, and uses very limited resources. I see no real reason to remove from the default installation. -- Per Jessen, Zürich (20.5°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Roger Luedecke wrote:
On Tuesday, August 16, 2011 07:00:58 AM jdd wrote:
that said as apparmor is a silent application I don't know if it's usefull at all
Good point. I say we remove it from default.
If apparmor causes a problem, you'll know anyway - if it prevents unauthorized access, you don't _really_ need to know, but otherwise you would just do a regular review of the logfile. (is there any SNMP support for apparmor?)
In my experience, apparmor causes no problems, and uses very limited resources. I see no real reason to remove from the default installation. From what I have gathered so far the issue with app-armor is primarilly with networked services that aren't configured with the correct profile. If such is
On Wednesday, August 17, 2011 02:30:55 AM Per Jessen wrote: true, then the proper resolution would be to simply fix the Samba defaults and the corresponding AppArmor profiles. Plus it looks like we may get the desktop notifier after all, which in the rare instance of AppArmor blocking something will be much more immediately resolvable for the user since it will be announced. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, 16 Aug 2011 17:20:25 +0530, jdd
Le 16/08/2011 10:55, Sascha Peilicke a écrit :
For most users, the AppArmor experience only involves silently failing applications, as we lack desktop integration (as you mentioned). And it's one
I think most user have never any problme with apparmor; In fact I never had any
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS). not running a server here and being pretty aware of what's going through my "broadband" connection (512 kB/s) because there is so little of it, i don't see the need for apparmor. there isn't much *nix specific malware in the wild, so i don't really know why it's needed at all, outside of visible servers perhaps (for which i don't use openSUSE). -- phani. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 18:39, phanisvara das a écrit :
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
I install 50 machines each year (approx) an never had apparmor block anything. what is it blocking really? Samba? for what application (I can configure my dsl box through samba and dolphin right now without any problem) jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday, August 16, 2011 10:26:13 AM jdd wrote:
Le 16/08/2011 18:39, phanisvara das a écrit :
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
I install 50 machines each year (approx) an never had apparmor block anything.
what is it blocking really? Samba? for what application (I can configure my dsl box through samba and dolphin right now without any problem)
jdd How did you install? Was it a fresh DVD install of 11.4? If not, then you will experience fewer to no issues. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 22:02, Roger Luedecke a écrit :
How did you install? Was it a fresh DVD install of 11.4?
yes, most of the time jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
jdd wrote:
Le 16/08/2011 18:39, phanisvara das a écrit :
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
I install 50 machines each year (approx) an never had apparmor block anything.
I second that, although I don't do that many installs. I've filed a couple of bugreports on minor apparmor issues, but I've never needed to disable it. -- Per Jessen, Zürich (20.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 17 Aug 2011 14:52:13 +0530, Per Jessen
jdd wrote:
Le 16/08/2011 18:39, phanisvara das a écrit :
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
I install 50 machines each year (approx) an never had apparmor block anything.
I second that, although I don't do that many installs. I've filed a couple of bugreports on minor apparmor issues, but I've never needed to disable it.
i admit that the last time i actually looked into what apparmor was doing has been a long time ago. i guess i'll give it another try, if only to help debugging something that does have it's uses, though i still consider it unnecessary for myself. -- phani. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 17, 2011 at 03:42:12PM +0530, phanisvara das wrote:
On Wed, 17 Aug 2011 14:52:13 +0530, Per Jessen
wrote: jdd wrote:
Le 16/08/2011 18:39, phanisvara das a écrit :
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
I install 50 machines each year (approx) an never had apparmor block anything.
I second that, although I don't do that many installs. I've filed a couple of bugreports on minor apparmor issues, but I've never needed to disable it.
i admit that the last time i actually looked into what apparmor was doing has been a long time ago. i guess i'll give it another try, if only to help debugging something that does have it's uses, though i still consider it unnecessary for myself.
It usually is not enabled for most things. We enabled it for nmbd and smbd in 11.4, which due to very flexible nature of smb paths that can be served made it reject valid user scenarios. It is kind of hard to confine a service which offers read/write access to configurable paths. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 17, 2011 at 03:42:12PM +0530, phanisvara das wrote:
On Wed, 17 Aug 2011 14:52:13 +0530, Per Jessen
wrote: jdd wrote:
Le 16/08/2011 18:39, phanisvara das a écrit :
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
I install 50 machines each year (approx) an never had apparmor block anything.
I second that, although I don't do that many installs. I've filed a couple of bugreports on minor apparmor issues, but I've never needed to disable it.
i admit that the last time i actually looked into what apparmor was doing has been a long time ago. i guess i'll give it another try, if only to help debugging something that does have it's uses, though i still consider it unnecessary for myself.
It usually is not enabled for most things.
We enabled it for nmbd and smbd in 11.4, which due to very flexible nature of smb paths that can be served made it reject valid user scenarios. It is kind of hard to confine a service which offers read/write access to configurable paths.
Ciao, Marcus Hmm, sounds like a problematic addition. Maybe the restrictions should be
On Wednesday, August 17, 2011 04:34:46 AM Marcus Meissner wrote: lifted then. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 17, 2011 at 08:21:31AM -0700, Roger Luedecke wrote:
On Wednesday, August 17, 2011 04:34:46 AM Marcus Meissner wrote: [ 8< ]
i admit that the last time i actually looked into what apparmor was doing has been a long time ago. i guess i'll give it another try, if only to help debugging something that does have it's uses, though i still consider it unnecessary for myself.
It usually is not enabled for most things.
We enabled it for nmbd and smbd in 11.4, which due to very flexible nature of smb paths that can be served made it reject valid user scenarios. It is kind of hard to confine a service which offers read/write access to configurable paths.
Hmm, sounds like a problematic addition. Maybe the restrictions should be lifted then.
Sounds more like the YaST Samba module needs an enhancement if a new share gets added. In this case we have to add a fitting AppArmor configuration for this new path too if AppArmor is in use. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Wednesday, August 17, 2011 08:44:13 AM Lars Müller wrote:
On Wed, Aug 17, 2011 at 08:21:31AM -0700, Roger Luedecke wrote:
On Wednesday, August 17, 2011 04:34:46 AM Marcus Meissner wrote: [ 8< ]
i admit that the last time i actually looked into what apparmor was doing has been a long time ago. i guess i'll give it another try, if only to help debugging something that does have it's uses, though i still consider it unnecessary for myself.
It usually is not enabled for most things.
We enabled it for nmbd and smbd in 11.4, which due to very flexible nature of smb paths that can be served made it reject valid user scenarios. It is kind of hard to confine a service which offers read/write access to configurable paths.
Hmm, sounds like a problematic addition. Maybe the restrictions should be lifted then.
Sounds more like the YaST Samba module needs an enhancement if a new share gets added. In this case we have to add a fitting AppArmor configuration for this new path too if AppArmor is in use.
Lars Maybe. Question then is, does YaST and the sharing in Dolphin conflict? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 17, 2011 at 12:14:11PM -0700, Roger Luedecke wrote: [ 8< ]
Maybe. Question then is, does YaST and the sharing in Dolphin conflict?
Both modify /etc/samba/smb.conf _or_ make use of the net usershare feature or use the registry configuration feature (starting with 3.2 IIRC). Yes, we try hard to make the config matrix three-dimensional. :) One knowing Dolphin better please spot light for us on this. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Wednesday, August 17, 2011 12:34:07 PM Lars Müller wrote:
On Wed, Aug 17, 2011 at 12:14:11PM -0700, Roger Luedecke wrote: [ 8< ]
Maybe. Question then is, does YaST and the sharing in Dolphin conflict?
Both modify /etc/samba/smb.conf _or_ make use of the net usershare feature or use the registry configuration feature (starting with 3.2 IIRC). Yes, we try hard to make the config matrix three-dimensional. :)
One knowing Dolphin better please spot light for us on this.
Lars Yikes, that sounds rather complicated... is there any way to simplify Samba? Or heck, is there another sort of filesharing thing like it that is less cumbersome? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 17, 2011 at 12:47:09PM -0700, Roger Luedecke wrote:
On Wednesday, August 17, 2011 12:34:07 PM Lars Müller wrote:
On Wed, Aug 17, 2011 at 12:14:11PM -0700, Roger Luedecke wrote: [ 8< ]
Maybe. Question then is, does YaST and the sharing in Dolphin conflict?
Both modify /etc/samba/smb.conf _or_ make use of the net usershare feature or use the registry configuration feature (starting with 3.2 IIRC). Yes, we try hard to make the config matrix three-dimensional. :)
One knowing Dolphin better please spot light for us on this.
Yikes, that sounds rather complicated...
Dude, you sound rather lazy. It's not yet Friday. ;)
is there any way to simplify Samba?
See, here you have a mix of things and as soon as you mix stuff (think of a long drink) and you take it it sometimes makes your head turning round faster.
Or heck, is there another sort of filesharing thing like it that is less cumbersome?
Some will argue NFS. But even NFS got ACL support plus recent enahncements (richacls) to support NFSv4. So as soon as we're all living in the same ACLed world the difference isn't that big any longer. BTW welcome in this wonderful world. :) Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Hello, on Mittwoch, 17. August 2011, Lars Müller wrote:
On Wed, Aug 17, 2011 at 08:21:31AM -0700, Roger Luedecke wrote:
On Wednesday, August 17, 2011 04:34:46 AM Marcus Meissner wrote:
We enabled it for nmbd and smbd in 11.4, which due to very flexible nature of smb paths that can be served made it reject valid user scenarios. It is kind of hard to confine a service which offers read/write access to configurable paths.
Hmm, sounds like a problematic addition. Maybe the restrictions should be lifted then.
Sounds more like the YaST Samba module needs an enhancement if a new share gets added. In this case we have to add a fitting AppArmor configuration for this new path too if AppArmor is in use.
The YaST Samba module is the wrong place IMHO. The better place is the Samba initscript (and its systemd equivalent) so that it is also working for people who manually edit smb.conf. Copy&paste from my mail from yesterday (shortly before midnight) somewhere else in this thread: --------------------------------------------------------------------- The main problem is that AppArmor needs to be aware of the location of your shares. The perfect solution would be that Samba or its initscript add the location of all shares (with lrwk permissions) to an AppArmor profile sniplet at startup. See also https://bugzilla.novell.com/show_bug.cgi?id=688040 - most interesting comments: | Comment 2 - Christian Boltz 2011-04-18 22:11:35 CEST | Agreed. It would still be worth some bonus points if the samba | initscript would auto-generate a profile sniplet with the path of all | shares ;-) | Comment 3 - Lars Mueller 2011-04-20 18:30:08 CEST | Free coffee and cake if we see a submit request implementing the | suggestion from comment #2 in a way that it works generic with the | current sysvinit approach and with systemd too. Lars didn't write "for the submitter only" - maybe there's someone who wants to make him sponsoring coffee and cake for the conference? *eg* --------------------------------------------------------------------- The bugreport already contains some technical hints - we just need someone who implements it. (If needed, I can help on the AppArmor part.) Regards, Christian Boltz -- Frag nicht nach dem Tuning des Heckspoilers wenn Du eh in einer Tempo-30-Zone bist. [Peer Heinlein in postfixbuch-users] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/17/2011 01:39 PM, Christian Boltz wrote:
Hello,
on Mittwoch, 17. August 2011, Lars Müller wrote:
On Wed, Aug 17, 2011 at 08:21:31AM -0700, Roger Luedecke wrote:
On Wednesday, August 17, 2011 04:34:46 AM Marcus Meissner wrote:
We enabled it for nmbd and smbd in 11.4, which due to very flexible nature of smb paths that can be served made it reject valid user scenarios. It is kind of hard to confine a service which offers read/write access to configurable paths.
Hmm, sounds like a problematic addition. Maybe the restrictions should be lifted then.
Sounds more like the YaST Samba module needs an enhancement if a new share gets added. In this case we have to add a fitting AppArmor configuration for this new path too if AppArmor is in use.
The YaST Samba module is the wrong place IMHO. The better place is the Samba initscript (and its systemd equivalent) so that it is also working for people who manually edit smb.conf.
Copy&paste from my mail from yesterday (shortly before midnight) somewhere else in this thread:
---------------------------------------------------------------------
The main problem is that AppArmor needs to be aware of the location of your shares. The perfect solution would be that Samba or its initscript add the location of all shares (with lrwk permissions) to an AppArmor profile sniplet at startup.
See also https://bugzilla.novell.com/show_bug.cgi?id=688040 - most interesting comments:
| Comment 2 - Christian Boltz 2011-04-18 22:11:35 CEST | Agreed. It would still be worth some bonus points if the samba | initscript would auto-generate a profile sniplet with the path of all | shares ;-)
| Comment 3 - Lars Mueller 2011-04-20 18:30:08 CEST | Free coffee and cake if we see a submit request implementing the | suggestion from comment #2 in a way that it works generic with the | current sysvinit approach and with systemd too.
Lars didn't write "for the submitter only" - maybe there's someone who wants to make him sponsoring coffee and cake for the conference? *eg*
Another potential solution coming down the pipes are kernel vars and mount rules. Basically there could be a solution that doesn't have to directly update policy but only a single kernel var (easier to auto-gen), this could be done dynamically without having to reload all of policy. There are of course lots of details I have left out, and some more code to handle updating for shares would need to be created but at least for shares and dynamic filesystems I think there is a better solution coming than updating packages to do it.
---------------------------------------------------------------------
The bugreport already contains some technical hints - we just need someone who implements it. (If needed, I can help on the AppArmor part.)
Regards,
Christian Boltz
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, on Dienstag, 16. August 2011, phanisvara das wrote:
On Tue, 16 Aug 2011 17:20:25 +0530, jdd
wrote: I think most user have never any problme with apparmor; In fact I never had any
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
Please open a bugreport! Attach /var/log/audit/audit.log and I'm sure your problem will be solved (for you and all other users). You can CC me (I'm "suse-beta [at] cboltz DOT de" in bugzilla) in these cases - that might speed up things a bit. And always keep Pascal's wise words (see .signature) in mind! ;-) (This note is aimed at all people that uninstall AppArmor if it blocks something, not only at you.)
not running a server here and being pretty aware of what's going through my "broadband" connection (512 kB/s) because there is so little of it, i don't see the need for apparmor. there isn't much *nix specific malware in the wild, so i don't really know why it's needed at all,
Because some additional security can never hurt. Even if AppArmor can "only" prevent/block a single attack against your system, it was useful for you ;-) Regards, Christian Boltz -- Always file a bug: if it's not in Bugzilla, then it's not there ;) [Pascal Bleser in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 17 Aug 2011 02:53:56 +0530, Christian Boltz
Please open a bugreport! Attach /var/log/audit/audit.log and I'm sure your problem will be solved (for you and all other users). You can CC me (I'm "suse-beta [at] cboltz DOT de" in bugzilla) in these cases - that might speed up things a bit. And always keep Pascal's wise words (see .signature) in mind! (This note is aimed at all people that uninstall AppArmor if it blocks something, not only at you.)
i never perceived it as a bug really; just some piece of software that needs to be adjusted to what i want to run on my machine: SSH on strange ports, unencrypted authentication on the local network, https connection to untrusted hosts. i don't imagine apparmor will ever be able to have ready-made profiles for every thinkable configuration and use. and since i have neither plastic money, nor secrets worthwile stealing, or enough bandwidth to tempt bot nets, i rather skip the trouble that comes with added security. -- phani. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Aug 17, 2011 at 03:09:25AM +0530, phanisvara das wrote:
On Wed, 17 Aug 2011 02:53:56 +0530, Christian Boltz
wrote: Please open a bugreport! Attach /var/log/audit/audit.log and I'm sure your problem will be solved (for you and all other users). You can CC me (I'm "suse-beta [at] cboltz DOT de" in bugzilla) in these cases - that might speed up things a bit. And always keep Pascal's wise words (see .signature) in mind! (This note is aimed at all people that uninstall AppArmor if it blocks something, not only at you.)
i never perceived it as a bug really; just some piece of software that needs to be adjusted to what i want to run on my machine: SSH on strange ports, unencrypted authentication on the local network, https connection to untrusted hosts. i don't imagine apparmor will ever be able to have ready-made profiles for every thinkable configuration and use. and since i have neither plastic money, nor secrets worthwile stealing, or enough bandwidth to tempt bot nets, i rather skip the trouble that comes with added security.
botnets do not differ between targets. In my (and others) opinion every admin on the Internet has the responsibility to keep his/her machines secure. You are doing much of that already in other ways so I guess you are good ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, on Dienstag, 16. August 2011, phanisvara das wrote:
On Wed, 17 Aug 2011 02:53:56 +0530, Christian Boltz wrote:
Please open a bugreport! Attach /var/log/audit/audit.log and I'm sure your problem will be solved (for you and all other users). You can CC me (I'm "suse-beta [at] cboltz DOT de" in bugzilla) in these cases - that might speed up things a bit.
i never perceived it as a bug really; just some piece of software that needs to be adjusted to what i want to run on my machine:
That isn't completely wrong, but the AppArmor profiles that are enabled by default should work with nearly all configurations. In other words: please open a bugreport ;-) Unless I miss something, AppArmor will not block any of your examples:
SSH on strange ports,
AppArmor doesn't have support to specify a TCP or UDP port number in the profile (but IIRC it was discussed and it might be possible one day), which means the sshd profile will work for all ports.
unencrypted authentication on the local network,
This also isn't / can't be blocked by AppArmor - in fact I only had problems with encrypted authentification because a program wasn't allowed to read a SSL certificate ;-)
https connection to untrusted hosts.
Are you talking about self-signed certificates and certificates not signed by an expensive certificate authority? That's something your browser might block or warn you about, but AppArmor doesn't/can't do this (and never will, because it would mean to crack the https encryption or to do a local MITM attack). It looks to that you overestimate the features of AppArmor ;-) It has a set of "network" rules, but it can't check the port number or the content of the packages sent over the network. Do you have better examples why you uninstalled AppArmor? *g*
i don't imagine apparmor will ever be able to have ready-made profiles for every thinkable configuration and use.
That might be, but the target should be to have profiles that work for most configurations. Sorry if I repeat myself, but: please open a bugreport if your configuration isn't supported.
and since i have neither plastic money, nor secrets worthwile stealing, or enough bandwidth to tempt bot nets, i rather skip the trouble that comes with added security.
Well, your choice. I hope I'll never have to say you "I told you so" ;-)) Regards, Christian Boltz --
Wenn Du so willst... make RM="rm -rf /" clean Bin ich dann für die gelöschte Festplatte verantwortlich? ;-) Du hast gerade erkannt, warum es vorteilhaft sein kann, keine Shell/ Make-Variablen zu verwenden und Dinge stattdessen hart zu codieren ;-) [> Christian Boltz und Ralf Corsepius in suse-programming] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 17 Aug 2011 05:26:02 +0530, Christian Boltz
It looks to that you overestimate the features of AppArmor It has a set of "network" rules, but it can't check the port number or the content of the packages sent over the network. Do you have better examples why you uninstalled AppArmor? *g*
no, not really. i just uninstalled it whenever i received any message from it, or regarding it, because i decided i didn't need it. but i can enable / install it again, to provide debugging information. i do see that it has it's uses and don't mind helping to make apparmor more useful for those cases. that's what this mailing list is about, after all. -- phani. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday, August 16, 2011 02:23:56 PM Christian Boltz wrote:
Hello,
on Dienstag, 16. August 2011, phanisvara das wrote:
On Tue, 16 Aug 2011 17:20:25 +0530, jdd
wrote: I think most user have never any problme with apparmor; In fact I never had any
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
Please open a bugreport! Attach /var/log/audit/audit.log and I'm sure your problem will be solved (for you and all other users). You can CC me (I'm "suse-beta [at] cboltz DOT de" in bugzilla) in these cases - that might speed up things a bit. And always keep Pascal's wise words (see .signature) in mind! ;-)
(This note is aimed at all people that uninstall AppArmor if it blocks something, not only at you.)
not running a server here and being pretty aware of what's going through my "broadband" connection (512 kB/s) because there is so little of it, i don't see the need for apparmor. there isn't much *nix specific malware in the wild, so i don't really know why it's needed at all,
Because some additional security can never hurt. Even if AppArmor can "only" prevent/block a single attack against your system, it was useful for you ;-)
Regards,
Christian Boltz Good point, and I'll do just that. Not immediately though, I'm going to dinner. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 16 August 2011 23:23:56 Christian Boltz wrote:
Hello,
on Dienstag, 16. August 2011, phanisvara das wrote:
On Tue, 16 Aug 2011 17:20:25 +0530, jdd
wrote: I think most user have never any problme with apparmor; In fact I never had any
no problem really; i just un-install it as soon as it tries to block something i need (which happens soon after every fresh install of oS).
Please open a bugreport! Attach /var/log/audit/audit.log and I'm sure your problem will be solved (for you and all other users). You can CC me (I'm "suse-beta [at] cboltz DOT de" in bugzilla) in these cases - that might speed up things a bit. And always keep Pascal's wise words (see .signature) in mind! ;-) So you're the first one stepping up to actually fix something as it seems you do care for it. That's good.
(This note is aimed at all people that uninstall AppArmor if it blocks something, not only at you.)
not running a server here and being pretty aware of what's going through my "broadband" connection (512 kB/s) because there is so little of it, i don't see the need for apparmor. there isn't much *nix specific malware in the wild, so i don't really know why it's needed at all,
Because some additional security can never hurt. Even if AppArmor can "only" prevent/block a single attack against your system, it was useful for you ;-) Naa, that doesn't justify running apparmor+auditd on my laptop letting it drain the battery just for the case that I may run postfix on it (which has decent profiles). -- Mit freundlichen Grüßen, Sascha Peilicke
Am Tue, 16 Aug 2011 23:23:56 +0200
schrieb Christian Boltz
Please open a bugreport! Attach /var/log/audit/audit.log and I'm sure
https://bugzilla.novell.com/show_bug.cgi?id=694197
your problem will be solved (for you and all other users).
after a veeeeeeery loooooooong tiiiiiiiiimmmmeeeeeeeee. Seems apparmor really slows everyone down dramatically ;) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, on Donnerstag, 18. August 2011, Stefan Seyfried wrote:
Am Tue, 16 Aug 2011 23:23:56 +0200 schrieb Christian Boltz:
Please open a bugreport! Attach /var/log/audit/audit.log and I'm sure
Looks like I should add an "AppArmor bugs" safed search to my bugzilla saved searches ;-) - until now, I didn't see this bug. The bug you quoted is fixed in Factory, and I also commited the patch upstream.
your problem will be solved (for you and all other users).
after a veeeeeeery loooooooong tiiiiiiiiimmmmeeeeeeeee. Seems apparmor really slows everyone down dramatically ;)
I'm afraid that problem exists in more areas - unfortunately a day only has 24 hours, and not everybody wants to additionally work in the nights if the 24 hours aren't enough ;-)) Oh, BTW: adding /var/log/audit/audit.log to the bugreport usually speeds up AppArmor bugreports ;-) Regards, Christian Boltz -- Intel kauft McAfee. [...] Der Synergieeffekt ist offensichtlich. McAfee macht Computer so langsam, dass man eine neue Intel-CPU braucht. Ähnliche Synergieeffekte gibt es zwischen [...] Computerspielen und Grafikkartenbedarf und zwischen Webforen und Tischkantenbedarf. [http://blog.fefe.de/?ts=b2935cd1] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday, August 16, 2011 01:55:36 AM Sascha Peilicke wrote:
1. Have a simple default configuration for Samba, like in Ubuntu where it simply works out of the box.
a. Fix AppArmor so it isn't battling with Samba constantly.
2. AppArmor desktop notifier. It would be nice for the user to know when
AppArmor blocks something, and be able to click straight through to
the Profile Update wizard. But even somethin as simple as a system announcement would be superior and be picked up by the KDE notification system.
While the idea behind AppArmor is good, the whole concept dies without maintenance. Ideally, upstream projects would care for AppArmor profiles (as much as they would care for SELinux), or if not, beloved packagers would spend their precious time maintaing AppArmor profiles for each of the many thousands of packages that are currently in Factory.
Reality hits hard in that case, we have around 10 services that have really working, up-to-date AppArmor profiles. The other profiles we ship come from Ubuntu and do not necessarily match or packages. The packages with the most security issues have none (like Firefox, Flash player, Adobe Reader).
The question is, why do we force this onto (primarily) desktop users by default? I'm sure, the seasoned admins using openSUSE will cry out loud, how we could actually think about such a move. But really, we should either don't enable AppArmor and/or don't even install the packages by default. It just doesn't make any sense.
For most users, the AppArmor experience only involves silently failing applications, as we lack desktop integration (as you mentioned). And it's one of those daemons (together with auditd) that are usually removed first on any fresh installation.
Everyone that would complain about such a move is invited to fix the profiles we have or even create _and maintain_ new ones. Otherwise I proposing a grace period for people to step up and get rid of this for 12.1. However, the situation is completely different on SLE, but that's not to be discussed here, please. I generally have left AppArmor alone, despite seeing no real use for it in my case. Since it IS more useful for admins than it is for desktop end users, it would make alot more sense to remove it from the default install. Admins know what they need, and can easilly find it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, [please keep the CC in replies] on Dienstag, 16. August 2011, Sascha Peilicke wrote:
1. Have a simple default configuration for Samba, like in Ubuntu where it simply works out of the box.
a. Fix AppArmor so it isn't battling with Samba constantly.
The 11.4 profiles were buggy/incomplete, but this was fixed with an update in the meantime. Fixed bugs don't count as bugs anymore ;-) The main problem is that AppArmor needs to be aware of the location of your shares. The perfect solution would be that Samba or its initscript add the location of all shares (with lrwk permissions) to an AppArmor profile sniplet at startup. See also https://bugzilla.novell.com/show_bug.cgi?id=688040 - most interesting comments: | Comment 2 - Christian Boltz 2011-04-18 22:11:35 CEST | Agreed. It would still be worth some bonus points if the samba | initscript would auto-generate a profile sniplet with the path of all | shares ;-) | Comment 3 - Lars Mueller 2011-04-20 18:30:08 CEST | Free coffee and cake if we see a submit request implementing the | suggestion from comment #2 in a way that it works generic with the | current sysvinit approach and with systemd too. Lars didn't write "for the submitter only" - maybe there's someone who wants to make him sponsoring coffee and cake for the conference? *eg*
2. AppArmor desktop notifier. It would be nice for the user to know when AppArmor blocks something, and be able to click straight through to the Profile Update wizard. But even somethin as simple as a system announcement would be superior and be picked up by the KDE notification system.
There is aa-notify (accidently named /usr/sbin/aa-apparmor_notify in 11.4). Unfortunately it is underdocumented :-( and since it needs to start as root (for read permissions on audit.log), it should probably be started by init/systemd. There's a bit of configuration needed, I can write about the details if someone is interested. It works (well, see next paragraph) and gives you nice desktop notifications. Unfortunately a security feature of aa-notify strikes back - it drops privileges after startup and then can't access /var/log/audit/ anymore. I'm just sorting that out with Jamie (one of the AppArmor developers). Unless there is a patch, the workaround is chmod 755 /var/log/audit/ (or better use chgrp trusted and chmod 750) Well, it would have been the first program that I can just use without having to report a bug first ;-))
While the idea behind AppArmor is good, the whole concept dies without maintenance. Ideally, upstream projects would care for AppArmor profiles (as much as they would care for SELinux), or
Oh, upstream projects really care for SELinux? ;-)
if not, beloved packagers would spend their precious time maintaing AppArmor profiles for each of the many thousands of packages that are currently in Factory.
That would be too much ;-) My policy is that (at least) everything that listens on a network port should have a profile - yes, that means (and is) server usage mostly. I also have some profiles on my workstations for various daemons, and even have profiles for some small applications (and even scripts) to prevent that I shoot myself in the foot ;-) Needless to say that the foot-protecting profiles are very special for my usecase and nothing that can or should be packaged. For protecting desktop applications, see the Firefox example below.
Reality hits hard in that case, we have around 10 services that have really working, up-to-date AppArmor profiles.
I count 23 profiles in /etc/apparmor.d/ that were installed by rpm on 11.4. OK, 7 of them are for usr/lib/dovecot/* which you might have counted as "1 set of dovecot profiles", but that's still more than 10 ;-)
The other profiles we ship come from Ubuntu
Not too surprising given who has the AppArmor developers on the payroll nowadays...
and do not necessarily match or packages.
I tend to disagree - see (several paragraphs) below ;-)
The packages with the most security issues have none (like Firefox,
The problem with Firefox (and most "desktop" applications) is: You don't know what the users will be doing with them ;-) The best example is downloading files - if you want to make Firefox really secure, you can limit write access (which includes downloads) to /home/*/downloads/**. However I'm quite sure that you'll then get lots of complaints because of "I can't download files to ~/coolstuff/" ;-) The alternative that will avoid this complaints is basically this rule: /** rw, but this isn't really more secure than not having a profile at all. (In fact, someone already posted a modified firefox profile with such a rule in bugzilla - but I'm quite sure this will be rejected upstream. Instead of /**, you could of course use /home/**, /tmp/**, /var/tmp/** as possible download locations - but that's already what the filesystem permissions make from the /** rule, so it isn't more secure. (A normal user doesn't have write permissions at other places, and if someone runs Firefox as root, well - I don't even want to think about that...)
Flash player,
It might be possible to create a profile for it - AFAIK it doesn't allow to save files to disk (except its own config and cookies - but this location is hardcoded). The question is which binary to confine - npviewer.bin might be the best candidate. (Does anybody know if npviewer.bin is only used for flash or also for other plugins?)
Adobe Reader).
Adobe reader has two menu entries "Save a copy" and "Save as text", which causes the same problems as described for firefox.
The question is, why do we force this onto (primarily) desktop users by default?
Because even the desktop users are protected by some profiles, for example nscd and syslog run on every system and come with active (and working!) apparmor profiles by default.
I'm sure, the seasoned admins using openSUSE will cry out loud, how we could actually think about such a move. But really, we should either don't enable AppArmor and/or don't even install the packages by default. It just doesn't make any sense.
For most users, the AppArmor experience only involves silently failing applications,
The applications should at least display a "permission denied" error message. If not, it's a bug in the application. (And yes, knowing how to solve that "permission denied" is left to the user, similar to wrong file/directory permissions.)
as we lack desktop integration (as you mentioned).
No, see aa-notify above.
And it's one of those daemons (together with auditd) that are usually removed first on any fresh installation.
Huh? Really?
Everyone that would complain about such a move is invited to fix the profiles we have or even create _and maintain_ new ones.
Sounds like I should blog more instead of silently doing the work ;-) I already pushed several profile updates and other patches upstream (both own changes and patches in the openSUSE package), maintain the apparmor syntax highlighing file for vim and in the meantime I also have commit access in the AppArmor bzr repo :-) That said: The best person to maintain a profile is a person who actually uses the profiled application. The reason for this is that nearly every application that does more than printing "hello world" has several config options that might influence which files are accessed. (I know AppArmor very well, but if you tell me "create a profile for $application" it will lack lots of rules if I'm not familiar with $application.)
Otherwise I proposing a grace period for people to step up and get rid of this for 12.1.
Does the above text count? ;-)
However, the situation is completely different on SLE, but that's not to be discussed here, please.
Sorry to ignore your request, but openSUSE is still the base for SLE AFAIK. And with AppArmor disabled by default in openSUSE, you'll have more "fun" with the SLE customers when it's enabled by default because less people use/test it in openSUSE ;-) <BOfH> But why should I care - I don't use SLE *eg* </BOfH> But the most important point is: it would be a loss for openSUSE if AppArmor would be disabled by default. Regards, Christian Boltz -- Ich springe so oft aus dem Fenster, daß ich ein schnurloses Telefon habe. [Ratti in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday, August 16, 2011 02:43:37 PM Christian Boltz wrote:
There is aa-notify (accidently named /usr/sbin/aa-apparmor_notify in 11.4). Unfortunately it is underdocumented :-( and since it needs to start as root (for read permissions on audit.log), it should probably be started by init/systemd.
There's a bit of configuration needed, I can write about the details if someone is interested. It works (well, see next paragraph) and gives you nice desktop notifications.
Unfortunately a security feature of aa-notify strikes back - it drops privileges after startup and then can't access /var/log/audit/ anymore. I'm just sorting that out with Jamie (one of the AppArmor developers). Unless there is a patch, the workaround is chmod 755 /var/log/audit/ (or better use chgrp trusted and chmod 750) Well now, then we just need to get this working then. That will be a massive boon. Quite frankly I can't imagine why this wouldn't have been a priority. The majority of Linux/openSUSE users I know are home desktop users. In fact, I only know one person who uses a non-enterprise supported Linux in a corporate space... which is openSUSE proudly enough. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, on Mittwoch, 17. August 2011, Roger Luedecke wrote:
On Tuesday, August 16, 2011 02:43:37 PM Christian Boltz wrote:
There is aa-notify (accidently named /usr/sbin/aa-apparmor_notify in 11.4). [...] Unfortunately a security feature of aa-notify strikes back - it drops privileges after startup and then can't access /var/log/audit/ anymore. I'm just sorting that out with Jamie (one of the AppArmor developers). Unless there is a patch, the workaround is chmod 755 /var/log/audit/ (or better use chgrp trusted and chmod 750)
Well now, then we just need to get this working then. That will be a massive boon. Quite frankly I can't imagine why this wouldn't have been a priority. The majority of Linux/openSUSE users I know are home desktop users. In fact, I only know one person who uses a non-enterprise supported Linux in a corporate space... which is openSUSE proudly enough.
For some reason, the answer from John Johansen didn't reach
opensuse-factory. Therefore I'm forwarding it manually:
---------- Weitergeleitete Nachricht ----------
Datum: Mittwoch, 17. August 2011 06:42
Von: John Johansen
On 8/17/2011 12:12 AM, Roger Luedecke wrote:
On Tuesday, August 16, 2011 02:43:37 PM Christian Boltz wrote:
There is aa-notify (accidently named /usr/sbin/aa-apparmor_notify in 11.4). Unfortunately it is underdocumented :-( and since it needs to start as root (for read permissions on audit.log), it should probably be started by init/systemd.
There's a bit of configuration needed, I can write about the details if someone is interested. It works (well, see next paragraph) and gives you nice desktop notifications.
Unfortunately a security feature of aa-notify strikes back - it drops privileges after startup and then can't access /var/log/audit/ anymore. I'm just sorting that out with Jamie (one of the AppArmor developers). Unless there is a patch, the workaround is chmod 755 /var/log/audit/ (or better use chgrp trusted and chmod 750) Well now, then we just need to get this working then. That will be a massive boon. Quite frankly I can't imagine why this wouldn't have been a priority. The majority of Linux/openSUSE users I know are home desktop users. In fact, I only know one person who uses a non-enterprise supported Linux in a corporate space... which is openSUSE proudly enough.
I do. (well, our operation probably does not yet qualify as "enterprise" depending on who you talk to, but it's growing not shrinking or static and we're an application service provider as well as the developers of the main application being served. Other companies run their whole businesses on our software and servers so I am charged with maintaining a very high standard of availability, recoverability, and performance. It's a lot of users and they're all businesses and it's the life blood of their business in each case and some of them are big and doing a lot of business, so it's very important to each of them and I could use anything I want, money/licensing isn't an issue.) My main reason for specifying opensuse instead of sles was actually not money but compatibility/standardization and availability. That's a small sentence but impacts many areas both directly and indirectly and it adds up to be a big deal. Not even all selfish ones either. I don't want to waste my time figuring out and then documenting for others how to do something cool, or working on some package to make either the package or the OS integration better, that only works on SLE and is only available to the few people running SLE. My main reasons for specifying suse-anything instead of other equally non commercial yet mature distros like fedora/centos, debian, gentoo, or arch, don't seem to really exist any more, or at least are not as true as in the past. Don't read that as "suse was good but now it sux". It implies changes over time in 4 different areas. Changes (and lack of) in suse, changes in other distros, changes in the underlying constituent software common to all distros, changes in myself. Most of the reasons I specifically use opensuse would actually apply just about as well to several other non commercial distros. It's mostly inertia and maintaining standardization across my operation at this point. There's no especially strong reason to use opensuse now, but neither is there any especially strong reason not to. It's got it's pro's & cons, and it's fine. But for now I specifically use opensuse for everything across the board including the main internet-facing, customer-using, application workhorse servers. I maximize the pros and minimize the cons and all in all it's still a nice tidy predictable usable safe dependable efficient system. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Roger Luedecke wrote:
massive boon. Quite frankly I can't imagine why this wouldn't have been a priority. The majority of Linux/openSUSE users I know are home desktop users. In fact, I only know one person who uses a non-enterprise supported Linux in a corporate space... which is openSUSE proudly enough.
I've been running my business on openSUSE/SUSE since 2004. For small business with decent Linux-skills, I see little need for SLED/S. -- Per Jessen, Zürich (21.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello,
While the idea behind AppArmor is good, the whole concept dies without maintenance. Ideally, upstream projects would care for AppArmor profiles (as much as they would care for SELinux), or
Oh, upstream projects really care for SELinux? ;-) At least as much as they do for AppArmor ;-)
if not, beloved packagers would spend their precious time maintaing AppArmor profiles for each of the many thousands of packages that are currently in Factory.
That would be too much ;-) Consider it whishful thinking :-)
My policy is that (at least) everything that listens on a network port should have a profile - yes, that means (and is) server usage mostly. I also have some profiles on my workstations for various daemons, and even have profiles for some small applications (and even scripts) to prevent that I shoot myself in the foot ;-) Needless to say that the foot-protecting profiles are very special for my usecase and nothing that can or should be packaged. Sounds very reasonable, how about submitting those profiles? Still this somehow supports my argument that it is very useful on servers, less so on end-user machines.
For protecting desktop applications, see the Firefox example below.
Reality hits hard in that case, we have around 10 services that have really working, up-to-date AppArmor profiles.
I count 23 profiles in /etc/apparmor.d/ that were installed by rpm on 11.4. OK, 7 of them are for usr/lib/dovecot/* which you might have counted as "1 set of dovecot profiles", but that's still more than 10 ;-)
The other profiles we ship come from Ubuntu
Not too surprising given who has the AppArmor developers on the payroll nowadays...
and do not necessarily match or packages.
I tend to disagree - see (several paragraphs) below ;-)
The packages with the most security issues have none (like Firefox,
The problem with Firefox (and most "desktop" applications) is: You don't know what the users will be doing with them ;-) Right, the profiles would be rather complex, you might say. For stuff that changes as frequently as Firefox (plus all the plugins) is quite a task.
The best example is downloading files - if you want to make Firefox really secure, you can limit write access (which includes downloads) to /home/*/downloads/**. However I'm quite sure that you'll then get lots of complaints because of "I can't download files to ~/coolstuff/" ;-)
The alternative that will avoid this complaints is basically this rule: /** rw, but this isn't really more secure than not having a profile at all. (In fact, someone already posted a modified firefox profile with such a rule in bugzilla - but I'm quite sure this will be rejected upstream.
Instead of /**, you could of course use /home/**, /tmp/**, /var/tmp/** as possible download locations - but that's already what the filesystem permissions make from the /** rule, so it isn't more secure. (A normal user doesn't have write permissions at other places, and if someone runs Firefox as root, well - I don't even want to think about that...)
Flash player,
It might be possible to create a profile for it - AFAIK it doesn't allow to save files to disk (except its own config and cookies - but this location is hardcoded).
The question is which binary to confine - npviewer.bin might be the best candidate. (Does anybody know if npviewer.bin is only used for flash or also for other plugins?)
Adobe Reader).
Adobe reader has two menu entries "Save a copy" and "Save as text", which causes the same problems as described for firefox.
The question is, why do we force this onto (primarily) desktop users by default?
Because even the desktop users are protected by some profiles, for example nscd and syslog run on every system and come with active (and working!) apparmor profiles by default.
I'm sure, the seasoned admins using openSUSE will cry out loud, how we could actually think about such a move. But really, we should either don't enable AppArmor and/or don't even install the packages by default. It just doesn't make any sense.
For most users, the AppArmor experience only involves silently failing applications,
The applications should at least display a "permission denied" error message. If not, it's a bug in the application. (And yes, knowing how to solve that "permission denied" is left to the user, similar to wrong file/directory permissions.)
as we lack desktop integration (as you mentioned).
No, see aa-notify above.
And it's one of those daemons (together with auditd) that are usually removed first on any fresh installation.
Huh? Really? Depends, you might say, not for you. But we're both vocal minorities, maybe it's more right to just state that noone cares?
Everyone that would complain about such a move is invited to fix the profiles we have or even create _and maintain_ new ones.
Sounds like I should blog more instead of silently doing the work ;-)
That's the spirit, seems like I reached the correct guy here.
I already pushed several profile updates and other patches upstream (both own changes and patches in the openSUSE package), maintain the apparmor syntax highlighing file for vim and in the meantime I also have commit access in the AppArmor bzr repo :-)
That said: The best person to maintain a profile is a person who actually uses the profiled application. The reason for this is that nearly every application that does more than printing "hello world" has several config options that might influence which files are accessed. (I know AppArmor very well, but if you tell me "create a profile for $application" it will lack lots of rules if I'm not familiar with $application.)
Otherwise I proposing a grace period for people to step up and get rid of this for 12.1.
Does the above text count? ;-)
You don't demand that from our regular users? I mean I only got some insights into writing profiles recently, as I'm forced to do it (you know, policy @work). Still I'm having a hard time confining a daemon running in a Java servlet container (no, not tomcat) with many plugins, auto-update and that polls stuff in the interwebs. The only thing I learned so far that this isn't childsplay :-)
However, the situation is completely different on SLE, but that's not to be discussed here, please.
Sorry to ignore your request, but openSUSE is still the base for SLE AFAIK. And with AppArmor disabled by default in openSUSE, you'll have more "fun" with the SLE customers when it's enabled by default because less people use/test it in openSUSE ;-) <BOfH> But why should I care - I don't use SLE *eg* </BOfH>
But the most important point is: it would be a loss for openSUSE if AppArmor would be disabled by default.
It's merely about opt-in or opt-out and thus, which is more reasonable. Given the current state of our AppArmor integration and the huge community demand, I doubt that. But that's what this thread should be about. -- Mit freundlichen Grüßen, Sascha Peilicke
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/17/2011 01:21 AM, Sascha Peilicke wrote:
Hello,
While the idea behind AppArmor is good, the whole concept dies without maintenance. Ideally, upstream projects would care for AppArmor profiles (as much as they would care for SELinux), or
Oh, upstream projects really care for SELinux? ;-) At least as much as they do for AppArmor ;-)
sadly it is mostly wishful thinking but there are actually a few projects that care.
if not, beloved packagers would spend their precious time maintaing AppArmor profiles for each of the many thousands of packages that are currently in Factory.
That would be too much ;-) Consider it whishful thinking :-)
:)
My policy is that (at least) everything that listens on a network port should have a profile - yes, that means (and is) server usage mostly. I also have some profiles on my workstations for various daemons, and even have profiles for some small applications (and even scripts) to prevent that I shoot myself in the foot ;-) Needless to say that the foot-protecting profiles are very special for my usecase and nothing that can or should be packaged. Sounds very reasonable, how about submitting those profiles? Still this somehow supports my argument that it is very useful on servers, less so on end-user machines.
For protecting desktop applications, see the Firefox example below.
Reality hits hard in that case, we have around 10 services that have really working, up-to-date AppArmor profiles.
I count 23 profiles in /etc/apparmor.d/ that were installed by rpm on 11.4. OK, 7 of them are for usr/lib/dovecot/* which you might have counted as "1 set of dovecot profiles", but that's still more than 10 ;-)
The other profiles we ship come from Ubuntu
Not too surprising given who has the AppArmor developers on the payroll nowadays...
and do not necessarily match or packages.
I tend to disagree - see (several paragraphs) below ;-)
The packages with the most security issues have none (like Firefox,
The problem with Firefox (and most "desktop" applications) is: You don't know what the users will be doing with them ;-) Right, the profiles would be rather complex, you might say. For stuff that changes as frequently as Firefox (plus all the plugins) is quite a task.
Right system level profiles for firefox have to be very loose. What is needed here is the ability for users to add their own policy.
The best example is downloading files - if you want to make Firefox really secure, you can limit write access (which includes downloads) to /home/*/downloads/**. However I'm quite sure that you'll then get lots of complaints because of "I can't download files to ~/coolstuff/" ;-)
The alternative that will avoid this complaints is basically this rule: /** rw, but this isn't really more secure than not having a profile at all. (In fact, someone already posted a modified firefox profile with such a rule in bugzilla - but I'm quite sure this will be rejected upstream.
Instead of /**, you could of course use /home/**, /tmp/**, /var/tmp/** as possible download locations - but that's already what the filesystem permissions make from the /** rule, so it isn't more secure. (A normal user doesn't have write permissions at other places, and if someone runs Firefox as root, well - I don't even want to think about that...)
owner @{HOME}/** rw,
would be even better
Flash player,
It might be possible to create a profile for it - AFAIK it doesn't allow to save files to disk (except its own config and cookies - but this location is hardcoded).
The question is which binary to confine - npviewer.bin might be the best candidate. (Does anybody know if npviewer.bin is only used for flash or also for other plugins?)
Adobe Reader).
Adobe reader has two menu entries "Save a copy" and "Save as text", which causes the same problems as described for firefox.
The question is, why do we force this onto (primarily) desktop users by default?
Because even the desktop users are protected by some profiles, for example nscd and syslog run on every system and come with active (and working!) apparmor profiles by default.
I'm sure, the seasoned admins using openSUSE will cry out loud, how we could actually think about such a move. But really, we should either don't enable AppArmor and/or don't even install the packages by default. It just doesn't make any sense.
For most users, the AppArmor experience only involves silently failing applications,
The applications should at least display a "permission denied" error message. If not, it's a bug in the application. (And yes, knowing how to solve that "permission denied" is left to the user, similar to wrong file/directory permissions.)
as we lack desktop integration (as you mentioned).
No, see aa-notify above.
And it's one of those daemons (together with auditd) that are usually removed first on any fresh installation.
Huh? Really? Depends, you might say, not for you. But we're both vocal minorities, maybe it's more right to just state that noone cares?
Well things like application containment and auditing are things that the majority shouldn't have to care about usually. Its only when something goes wrong and that the user should care about them. So yeah noone cares is close to the truth :/
Everyone that would complain about such a move is invited to fix the profiles we have or even create _and maintain_ new ones.
Sounds like I should blog more instead of silently doing the work ;-)
That's the spirit, seems like I reached the correct guy here.
I already pushed several profile updates and other patches upstream (both own changes and patches in the openSUSE package), maintain the apparmor syntax highlighing file for vim and in the meantime I also have commit access in the AppArmor bzr repo :-)
That said: The best person to maintain a profile is a person who actually uses the profiled application. The reason for this is that nearly every application that does more than printing "hello world" has several config options that might influence which files are accessed. (I know AppArmor very well, but if you tell me "create a profile for $application" it will lack lots of rules if I'm not familiar with $application.)
its not just familiarity but because it doesn't fit your usage model. This really cries out for crowd sourcing, where different updates and configs can be loaded to a repository that can be used to help build better profiles.
We had a start on this once and there is movement in this direction again.
Otherwise I proposing a grace period for people to step up and get rid of this for 12.1.
Does the above text count? ;-) You don't demand that from our regular users? I mean I only got some insights into writing profiles recently, as I'm forced to do it (you know, policy @work). Still I'm having a hard time confining a daemon running in a Java servlet container (no, not tomcat) with many plugins, auto-update and that polls stuff in the interwebs. The only thing I learned so far that this isn't childsplay :-)
nope, though feel free to ask for help on the apparmor ml or irc (#apparmor@irc.oftc.net).
However, the situation is completely different on SLE, but that's not to be discussed here, please.
Sorry to ignore your request, but openSUSE is still the base for SLE AFAIK. And with AppArmor disabled by default in openSUSE, you'll have more "fun" with the SLE customers when it's enabled by default because less people use/test it in openSUSE ;-) <BOfH> But why should I care - I don't use SLE *eg* </BOfH>
But the most important point is: it would be a loss for openSUSE if AppArmor would be disabled by default.
It's merely about opt-in or opt-out and thus, which is more reasonable. Given the current state of our AppArmor integration and the huge community demand, I doubt that. But that's what this thread should be about.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5L9tAACgkQxAVxIsEKI+bvxgCgjhxtAL2335J5D8alqMD65esk 54UAn3GcS/kYh0k9mI3XSUrFD8Fbb35O =obH2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, on Mittwoch, 17. August 2011, John Johansen wrote:
On 08/17/2011 01:21 AM, Sascha Peilicke wrote:
Christian Boltz wrote:
My policy is that (at least) everything that listens on a network port should have a profile - yes, that means (and is) server usage mostly. I also have some profiles on my workstations for various daemons, and even have profiles for some small applications (and even scripts) to prevent that I shoot myself in the foot ;-) Needless to say that the foot-protecting profiles are very special for my usecase and nothing that can or should be packaged.
Sounds very reasonable, how about submitting those profiles?
John and the other AppArmor developers can tell you that I _did_ submit my profiles upstream. Some of them are already in bzr, some others are still pending for review [1]. As I said, my "foot-protecting" profiles that I use for some very special cases are an exception - those profiles would be useless or even counter-productive for other people ;-)
Still this somehow supports my argument that it is very useful on servers, less so on end-user machines.
"less useful" != "useless". On end-user machines, at least some daemons that run by default (nscd, klogd, syslog*, ahavi-daemon) and some small binaries (for example ping and traceroute) are protected by default. I wouldn't call that useless ;-) But yes, on a server there are more applications that you can protect quite easy (compared to protecting firefox, which is difficult for the reasons I explained yesterday).
The best example is downloading files - if you want to make Firefox really secure, you can limit write access (which includes downloads) to /home/*/downloads/**. However I'm quite sure that you'll then get lots of complaints because of "I can't download files to ~/coolstuff/" ;-)
The alternative that will avoid this complaints is basically this rule: /** rw,
but this isn't really more secure than not having a profile at all. (In fact, someone already posted a modified firefox profile with such a rule in bugzilla - but I'm quite sure this will be rejected upstream.
Instead of /**, you could of course use /home/**, /tmp/**, /var/tmp/** as possible download locations - but that's already what the filesystem permissions make from the /** rule, so it isn't more secure. (A normal user doesn't have write permissions at other places, and if someone runs Firefox as root, well - I don't even want to think about that...)
owner @{HOME}/** rw,
would be even better
Yes, of course - but in practise it doesn't change too much. A normal user (hopefully) doesn't have write permissions in another user's home. And if you don't include /tmp/**, people will probably complain that they can't download a file to /tmp (which might be a valid location for "download, unpack and delete the zip/tarball" downloads). I know about owner restrictions etc. - but my point is that a firefox profile that makes everybody happy (by allowing storing downloads anywhere) does not really help security-wise. And a "secure" firefox profile (restricted to ~/downloads) will cause lots of complaints ;-)
Everyone that would complain about such a move is invited to fix the profiles we have or even create _and maintain_ new ones.
Sounds like I should blog more instead of silently doing the work ;-)
That's the spirit, seems like I reached the correct guy here.
;-)
That said: The best person to maintain a profile is a person who actually uses the profiled application. The reason for this is that nearly every application that does more than printing "hello world" has several config options that might influence which files are accessed. (I know AppArmor very well, but if you tell me "create a profile for $application" it will lack lots of rules if I'm not familiar with $application.)
its not just familiarity but because it doesn't fit your usage model. This really cries out for crowd sourcing,
Exactly!
Otherwise I proposing a grace period for people to step up and get rid of this for 12.1.
Does the above text count? ;-)
You don't demand that from our regular users? I mean I only got some insights into writing profiles recently, as I'm forced to do it (you know, policy @work). Still I'm having a hard time confining a daemon running in a Java servlet container (no, not tomcat) with many plugins, auto-update and that polls stuff in the interwebs.
Sounds interesting, but not impossible. For comparison: I have a working profile for Apache with lots of vHosts, which includes Typo3 and many more "big" applications that are quite funny to profile. You won't get a complete profile for such a setup in an hour (because you'll always miss something). The solution is: switch the profile to complain mode for some days, run logprof from time to time and finally switch the profile to enforce mode.
The only thing I learned so far that this isn't childsplay :-)
IMHO using aa-genprof or aa-logprof isn't really hard. The only precondition is that you know what the permission flags mean. Some of them are obvious (like r and w), and you can learn the other ones in 30 minutes. Yes, I'm sure about the 30 minutes because I did a talk about AppArmor at LinuxTag 2009 which took less than 30 minutes ;-) If I find some free time at the conference (might be difficult because I probably can only come on sunday), I can provide you (and of course everybody else who is interested) with a short AppArmor workshop.
nope, though feel free to ask for help on the apparmor ml or irc (#apparmor@irc.oftc.net).
But the most important point is: it would be a loss for openSUSE if AppArmor would be disabled by default.
It's merely about opt-in or opt-out and thus, which is more reasonable. Given the current state of our AppArmor integration and the huge community demand, I doubt that. But that's what this thread should be about.
The question is what is worse: a) hindering a user by a too strict AppArmor profile (which is a rare event IMHO) b) an exploit in one of the confined daemons (nscd, syslog* etc.), while AppArmor would have prevented the exploit. That's hopefully also a rare event, but if it happens, it can have big consequences. Call me paranoid, but I clearly prefer being hindered by a too strict profile ;-) BTW: AFAIK there will be an AppArmor 2.7 beta release soon (mostly bugfixes compared to 2.6.x) - most probably early enough for inclusion in 12.1. Regards, Christian Boltz [1] for those who aren't involved with upstream AppArmor: There is a policy that all changes have to be reviewed (by sending a patch) before they are allowed to be commited to bzr. --
[wikibot] jfyi: we have an internal ruby script that works with iChain. we used it for the SDB migration (did you really expect we uploaded 2000pages manually?;) Considering you have nothing else to do, yes. ;-) [Marcus Rueckert and houghi in opensuse-wiki] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/17/2011 01:28 PM, Christian Boltz wrote:
Hello,
<< snip >>
The best example is downloading files - if you want to make Firefox really secure, you can limit write access (which includes downloads) to /home/*/downloads/**. However I'm quite sure that you'll then get lots of complaints because of "I can't download files to ~/coolstuff/" ;-)
The alternative that will avoid this complaints is basically this rule: /** rw,
but this isn't really more secure than not having a profile at all. (In fact, someone already posted a modified firefox profile with such a rule in bugzilla - but I'm quite sure this will be rejected upstream.
Instead of /**, you could of course use /home/**, /tmp/**, /var/tmp/** as possible download locations - but that's already what the filesystem permissions make from the /** rule, so it isn't more secure. (A normal user doesn't have write permissions at other places, and if someone runs Firefox as root, well - I don't even want to think about that...)
owner @{HOME}/** rw,
would be even better
Yes, of course - but in practise it doesn't change too much. A normal user (hopefully) doesn't have write permissions in another user's home. And if you don't include /tmp/**, people will probably complain that they can't download a file to /tmp (which might be a valid location for "download, unpack and delete the zip/tarball" downloads).
I know about owner restrictions etc. - but my point is that a firefox profile that makes everybody happy (by allowing storing downloads anywhere) does not really help security-wise. And a "secure" firefox profile (restricted to ~/downloads) will cause lots of complaints ;-)
yep, I have to agree currently firefox and desktop aps in general, are really limited to users who have admin rights and like tinkering, or at least don't mind having some restrictions. currently its the services underneath the desktop that should be targeted. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Aug 15, 2011 at 12:20:20PM -0700, Roger Luedecke wrote: [ 8< ]
There was also the matter of the pre 11 series behavior of AppArmor in blocking Samba; this I found was more pronounced in the DVD install. (To this day I can't get Samba to work properly in a DVD install.) Since I am not a developer, and have only a brief familiarity with many of the logistical issues facing a project of this magnitude I will not offer an immediate critique. However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed.
You misseed to quote the bug ID. "Lars, I've not filed one!" Then there is no issue. :) To quote one of my beloved Samba developer colleagues: "My life is driven by bugzilla!". Why I'm not able to find it in the quips list at https://bugzilla.samba.org/ is a different question. Please follow the instructuions we provide at http://en.openSUSE.org/Samba in the section titled "Samba bug reporting and advanced debugging information". Thanks. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Tuesday, August 16, 2011 10:15:11 AM Lars Müller wrote:
On Mon, Aug 15, 2011 at 12:20:20PM -0700, Roger Luedecke wrote: [ 8< ]
There was also the matter of the pre 11 series behavior of AppArmor in blocking Samba; this I found was more pronounced in the DVD install. (To this day I can't get Samba to work properly in a DVD install.) Since I am not a developer, and have only a brief familiarity with many of the logistical issues facing a project of this magnitude I will not offer an immediate critique. However as an Ambassador I must emphasize that these sort of anomalies, no matter how technically minor will shake the confidence of someone trying the new release. The things that we may consider minor, a new user will consider to be clues to the overall experience and what to expect; this is especially true for new users coming from Windows. Thus we lose a potential asset to the community in favor of some other distro (usually Ubuntu, Mint, Fedora, or Mandriva). Frankly, I would rather we be a bit late on releasing 12.1 than to release it as finished with the same sort of issues 11.4 showed.
You misseed to quote the bug ID.
"Lars, I've not filed one!"
Then there is no issue. :) To quote one of my beloved Samba developer colleagues: "My life is driven by bugzilla!". Why I'm not able to find it in the quips list at https://bugzilla.samba.org/ is a different question.
Please follow the instructuions we provide at http://en.openSUSE.org/Samba in the section titled "Samba bug reporting and advanced debugging information".
Thanks.
Lars I don't understand the issue well enough since I don't really understand how Samba works anyway. Thus my bug reports would be useless. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Aug 16, 2011 at 01:00:49PM -0700, Roger Luedecke wrote: [ 8< ]
I don't understand the issue well enough since I don't really understand how Samba works anyway. Thus my bug reports would be useless.
Under this conditions nobody can help you. I strongly suggest to try to follow the insrructions I gave with my last mail. If you don't try it you'll never learn it. And maybe we miss the greatest issue ever seen. ;) Thanks. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On 8/16/2011 4:35 PM, Lars Müller wrote:
On Tue, Aug 16, 2011 at 01:00:49PM -0700, Roger Luedecke wrote: [ 8< ]
I don't understand the issue well enough since I don't really understand how Samba works anyway. Thus my bug reports would be useless.
Under this conditions nobody can help you.
I strongly suggest to try to follow the insrructions I gave with my last mail. If you don't try it you'll never learn it.
And maybe we miss the greatest issue ever seen. ;)
Thanks.
Lars
Incorrect and missing the point. Under these conditions, Ubuntu and Mint etc DID help him. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Aug 16, 2011 at 04:48:22PM -0400, Brian K. White wrote:
On 8/16/2011 4:35 PM, Lars Müller wrote:
On Tue, Aug 16, 2011 at 01:00:49PM -0700, Roger Luedecke wrote: [ 8< ]
I don't understand the issue well enough since I don't really understand how Samba works anyway. Thus my bug reports would be useless.
Under this conditions nobody can help you.
I strongly suggest to try to follow the insrructions I gave with my last mail. If you don't try it you'll never learn it.
And maybe we miss the greatest issue ever seen. ;)
Thanks.
Incorrect and missing the point.
Under these conditions, Ubuntu and Mint etc DID help him.
Look, I try to get what's broken and don't like to get smacked around at this time of the day nor at any other. Either we get the details what's not working or we can't change the situation. It's my intention to turn the issue into a non issue. Telling me it works with other Linux vendors is telling my team colleagues and me what a terrible job we do. If that's your goal I can only thank you and wish you all the best. Well, have a lot of fun... Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Tue, Aug 16, 2011 at 04:48:22PM -0400, Brian K. White wrote:
On 8/16/2011 4:35 PM, Lars Müller wrote:
On Tue, Aug 16, 2011 at 01:00:49PM -0700, Roger Luedecke wrote: [ 8< ]
I don't understand the issue well enough since I don't really understand how Samba works anyway. Thus my bug reports would be useless.
Under this conditions nobody can help you.
I strongly suggest to try to follow the insrructions I gave with my last mail. If you don't try it you'll never learn it.
And maybe we miss the greatest issue ever seen. ;)
Thanks.
Incorrect and missing the point.
Under these conditions, Ubuntu and Mint etc DID help him.
Look, I try to get what's broken and don't like to get smacked around at this time of the day nor at any other.
Either we get the details what's not working or we can't change the situation. It's my intention to turn the issue into a non issue.
Telling me it works with other Linux vendors is telling my team colleagues and me what a terrible job we do. If that's your goal I can only thank you and wish you all the best.
Well, have a lot of fun...
Lars Whoa! Chill! Everybody just chill, this isn't how we roll. Both points are legitimate. I'll go over the stuf Lars linked to again and see if I can come up with something. My issue was simple, It didn't work at all and nothing seems to get it to work when installed from the DVD. Results are different in
On Tuesday, August 16, 2011 01:59:35 PM Lars Müller wrote: the LiveCD. Still wierd but working some. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 17/08/2011 02:33, Roger Luedecke a écrit :
seems to get it to work when installed from the DVD. Results are different in the LiveCD. Still wierd but working some.
that's really surprising, did you try with an other dvd? (I already found faulty dvd's) I really don't see what is different between the dvd and live cd + net load jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday, August 16, 2011 10:59:48 PM jdd wrote:
Le 17/08/2011 02:33, Roger Luedecke a écrit :
seems to get it to work when installed from the DVD. Results are different in the LiveCD. Still wierd but working some.
that's really surprising, did you try with an other dvd? (I already found faulty dvd's)
I really don't see what is different between the dvd and live cd + net load
jdd I seem to have misstated. The DVD install has been enormously problematic for Samba, but the LiveCD can work to a certain extent. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 17/08/2011 08:19, Roger Luedecke a écrit :
I seem to have misstated. The DVD install has been enormously problematic for Samba, but the LiveCD can work to a certain extent.
do you have a bugzilla report? can you elaborate? thanks jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday, August 17, 2011 04:40:06 AM jdd wrote:
Le 17/08/2011 08:19, Roger Luedecke a écrit :
I seem to have misstated. The DVD install has been enormously problematic for Samba, but the LiveCD can work to a certain extent.
do you have a bugzilla report? can you elaborate?
thanks jdd Samba can work on a LiveCD installation wiht a little fussing and updating AppArmor only once. DVD install never works no matter what I try. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 17/08/2011 17:19, Roger Luedecke a écrit :
AppArmor only once. DVD install never works no matter what I try.
I installed from dvd and doplphin was able to connect to my dsl box with samba without any problem. It's this "no matter what I try" that you should elaborate :-) what *exactly* did you do? thanks jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday, August 17, 2011 08:29:17 AM jdd wrote:
Le 17/08/2011 17:19, Roger Luedecke a écrit :
AppArmor only once. DVD install never works no matter what I try.
I installed from dvd and doplphin was able to connect to my dsl box with samba without any problem.
It's this "no matter what I try" that you should elaborate :-)
what *exactly* did you do?
thanks jdd I'm getting ready to setup a VM so I can take notes and what not on exactly what went wrong. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 17/08/2011 21:13, Roger Luedecke a écrit :
I'm getting ready to setup a VM so I can take notes and what not on exactly what went wrong.
thanks; and on a vm we should be able to do the same jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/08/2011 22:48, Brian K. White a écrit :
Incorrect and missing the point.
Under these conditions, Ubuntu and Mint etc DID help him.
but on some other points it's the other way round. I know case where unbuntu (or other) fail. anybody can fail on special case jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (22)
-
Basil Chupin
-
Brian K. White
-
Christian Boltz
-
Greg Freemyer
-
Greg KH
-
jdd
-
Johannes Meixner
-
John Johansen
-
Kim Leyendecker
-
Larry Finger
-
Lars Müller
-
Linda Walsh
-
Lukas Ocilka
-
Marcus Meissner
-
Per Jessen
-
phanisvara das
-
Roger Luedecke
-
Roman Bysh
-
Sascha Peilicke
-
Sid Boyce
-
Stefan Seyfried
-
Steven Sroka