[ale] SELinux & OOo

[Scott Castaline]

Jeff Hubbs wrote:
> I dealt with a great many similar situations years ago, but the OS in 
> question was VAX/SEVMS.  I suspect that the root cause may be 
> similar.  It seems that problems with running COTS apps in 
> SE<your_OS_here> tend to stem from the app, running under an ordinary 
> user account, trying to write back to "system" space that the 
> SE<whatever> arrangement has suddenly made ordinary-user-unwriteable.  
> Maybe with SELinux disabled, you can play around with lsof to see 
> where all OO is trying to reach.  Perhaps there is a logging level you 
> can activate that will dump access failures to a log.  Look for lock 
> files, cache areas - anywhere nonobvious that an app like OO might try 
> to open a file for write.
>
>
>
> Thompson Freeman wrote:
>> Scott
>>
>> You wouldn't happen to be running Fedora by any chance would you?
>>
>> Reason I ask. On the Fedora list there is a big moaning match set off 
>> by what sounds like a similar situation. There might be a clue in the 
>> mess of messages for you, but the thread went almost immediately into 
>> a "It isn't SELinux" "It is SELinux" feces flinging, or at least that 
>> was the feeling I got. So I'm deleting the thread and have missed any 
>> possible insights that might have appeared. But you can poke through 
>> the archives and see if anything mentioned helps should you desire.
>>
>>
>> Wish I had something more responsive and useful.
>>
>> On 10/17/2007 10:59:37 PM, Scott Castaline wrote:
>>> I was troubleshooting a minor issue with my HP printer and had 
>>> disabled SELinux to see if it was interfering. After determining 
>>> that SELinux was not the culprit, I re enabled, rebooted. The system 
>>> protested and stated that I needed to allow relabeling of my 
>>> harddrives, so I rebooted again to do this and now OOo will not 
>>> start. When I start from terminal I'll get: "no suitable windowing 
>>> system found, exiting.". If I set SELinux to permissive or disabled 
>>> OOo starts with no problem. The troubleshooter does not show any 
>>> errors. Any ideas why this would happen? I've already tried another 
>>> relabel, with no change. Permanent disable is not an option as we 
>>> have a couple of people in the complex that attack on a regular 
>>> basis. With the help of Charter we do have it narrowed down to 3 
>>> buildings, mine being one of them. So far my PC has been unscathed 
>>> since I started using SELinux, so I intend to keep it that way. My 
>>> wife's PC is a different story.
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://www.ale.org/mailman/listinfo/ale
>>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://www.ale.org/mailman/listinfo/ale
>>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>
It turned out to be SELinux. The message started showing up in the 
syslog file (messages), telling me to use the CLI command sealert -l 
{message #] and that brought up the actual file and suggested fix to the 
file giving the problem. It turned out that chcon -t command fixed it. 
I'm a happy camper again. The tip off came from the OOo users group 
list, but I think I will add the fix to the Fedora list that Thompson 
had mentioned.