Hello,
I've a strange issue over here, when enforcement mode bluetooth-applet will not
show up, but after waking from suspend it does.. any ideas on
what/where is causing
this to do so?
my .xsession-errors gives me warnings and a permissions denied, but
seems I cant figure why the
permission denied is happening in the first place
cat .xsession-errors
/etc/gnome/gdm/Xsession: Beginning session setup...
/etc/gnome/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent
-- ck-launch-session /usr/bin/startfluxbox
** (bluetooth-applet:2764): WARNING **: Could not open RFKILL control
device, please verify your installation
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
will not be saved or shared with other applications.
tint2 : nb monitor 1, nb monitor used 1, nb desktop 4
Error changing to home directory /root: Permission denied
Error changing to home directory /root: Permission denied
Error changing to home directory /root: Permission denied
NOTE: child process received `Goodbye', closing down
** Message: Initializing gksu extension...
Initializing nautilus-gdu extension
** (nautilus:3193): WARNING **: Could not inhibit power management:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name
"org.gnome.SessionManager" does not ex
** (gwibber:3262): WARNING **: Trying to register gtype
'WnckWindowState' as enum when in fact it is of type 'GFlags'
** (gwibber:3262): WARNING **: Trying to register gtype
'WnckWindowActions' as enum when in fact it is of type 'GFlags'
** (gwibber:3262): WARNING **: Trying to register gtype
'WnckWindowMoveResizeMask' as enum when in fact it is of type 'GFlags'
ERROR:dbus.proxies:Introspect error on
com.Gwibber.Messages:/com/gwibber/Messages:
dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.ServiceUnknown: The name
Gwibber.Messages was not provided by any .service files
Error changing to home directory /root: Permission denied
Error changing to home directory /root: Permission denied
Error changing to home directory /root: Permission denied
Error changing to home directory /root: Permission denied
the OS is a custom system I built.. the window manager is fluxbox if
there is any kind of info I can provide let me know.
--
Justin P. Mattock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/28/2010 03:50 PM, Justin Mattock wrote:
> Hello,
> I've a strange issue over here, when enforcement mode bluetooth-applet will not
> show up, but after waking from suspend it does.. any ideas on
> what/where is causing
> this to do so?
Judging from the .service files entries in the logs below i suspect you
are using Fedora rawhide here or a custom os based off of fedora rawhide?
In either case you can probably do the usual troubleshooting to narrow
things down a bit:
1. is this issue even selinux related; e.g. does it work in permissive mode.
= if selinux related issue (works in permissive mode); are there any avc
denials?
== if no avc denials use semodule -DB to unload "hidden denial rules"
then reproduce.
=== if avc denials: enclose and/or analyse
If its not an selinux issue may be a setuid/getgid / capability issue?
> my .xsession-errors gives me warnings and a permissions denied, but
> seems I cant figure why the
> permission denied is happening in the first place
>
> cat .xsession-errors
> /etc/gnome/gdm/Xsession: Beginning session setup...
> /etc/gnome/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent
> -- ck-launch-session /usr/bin/startfluxbox
>
> ** (bluetooth-applet:2764): WARNING **: Could not open RFKILL control
> device, please verify your installation
> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
> will not be saved or shared with other applications.
> tint2 : nb monitor 1, nb monitor used 1, nb desktop 4
> Error changing to home directory /root: Permission denied
> Error changing to home directory /root: Permission denied
> Error changing to home directory /root: Permission denied
> NOTE: child process received `Goodbye', closing down
> ** Message: Initializing gksu extension...
> Initializing nautilus-gdu extension
>
> ** (nautilus:3193): WARNING **: Could not inhibit power management:
> GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name
> "org.gnome.SessionManager" does not ex
>
> ** (gwibber:3262): WARNING **: Trying to register gtype
> 'WnckWindowState' as enum when in fact it is of type 'GFlags'
>
> ** (gwibber:3262): WARNING **: Trying to register gtype
> 'WnckWindowActions' as enum when in fact it is of type 'GFlags'
>
> ** (gwibber:3262): WARNING **: Trying to register gtype
> 'WnckWindowMoveResizeMask' as enum when in fact it is of type 'GFlags'
> ERROR:dbus.proxies:Introspect error on
> com.Gwibber.Messages:/com/gwibber/Messages:
> dbus.exceptions.DBusException:
> org.freedesktop.DBus.Error.ServiceUnknown: The name
> Gwibber.Messages was not provided by any .service files
> Error changing to home directory /root: Permission denied
> Error changing to home directory /root: Permission denied
> Error changing to home directory /root: Permission denied
> Error changing to home directory /root: Permission denied
>
>
> the OS is a custom system I built.. the window manager is fluxbox if
> there is any kind of info I can provide let me know.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0Z+2kACgkQMlxVo39jgT/NvACfWg8oZ7cKEfWlvkI6aLQb7G39
F6MAoLpmlxPMmFhxhi7HDs4oY4fvi24r
=K8v4
-----END PGP SIGNATURE-----
On 12/28/2010 06:59 AM, Dominick Grift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/28/2010 03:50 PM, Justin Mattock wrote:
>> Hello,
>> I've a strange issue over here, when enforcement mode bluetooth-applet will not
>> show up, but after waking from suspend it does.. any ideas on
>> what/where is causing
>> this to do so?
>
> Judging from the .service files entries in the logs below i suspect you
> are using Fedora rawhide here or a custom os based off of fedora rawhide?
>
neither.. just a from scratch system(used the guides here and there on
packages, but mostly went my own way)
> In either case you can probably do the usual troubleshooting to narrow
> things down a bit:
>
> 1. is this issue even selinux related; e.g. does it work in permissive mode.
>
works fine under permissive, as soon as enforcement the applet just
doesnt show up(under ps aux, it is starting)but after waking from S2R
the applet shows up(strange!!)
> = if selinux related issue (works in permissive mode); are there any avc
> denials?
>
> == if no avc denials use semodule -DB to unload "hidden denial rules"
> then reproduce.
>
> === if avc denials: enclose and/or analyse
>
yeah I've checked all of those(was thinking it's RFKILL related, but
then maybe it's not)I'll look again to see..
> If its not an selinux issue may be a setuid/getgid / capability issue?
>
could be...maybe what I did below, is the cause of this:
Using gdm + fluxbox + gnome-keyring there was some issues with the whole
session thing.. long story short I ended up adding:(taken from:
https://bbs.archlinux.org/viewtopic.php?id=67959)
# launches a session dbus instance
dbuslaunch="`which dbus-launch 2>/dev/null`"
if [ -n "$dbuslaunch" ] && [ -x "$dbuslaunch" ] && [ -z
"$DBUS_SESSION_BUS_ADDRESS" ]; then
eval `$dbuslaunch --sh-syntax --exit-with-session`
fi
in: /etc/gnome/gdm/Xsession
and also adding:
/usr/share/xsessions/fluxbox.desktop
Exec=ck-launch-session /usr/bin/startfluxbox
2656 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --daemonize
--login
2725 ? Ss 0:00 ck-launch-session /usr/bin/startfluxbox
2746 ? S 0:00 /usr/bin/dbus-launch --sh-syntax
--exit-with-session
2753 ? Ss 0:00 /usr/bin/ssh-agent -- ck-launch-session
/usr/bin/startfluxbox
2758 ? S 0:04 /usr/bin/fluxbox
2760 ? S 0:00 sh /home/justin/.fluxbox/startup
2761 ? Sl 0:00 /usr/bin/gnome-power-manager
2763 ? SLl 0:00 nm-applet --sm-disable
2764 ? S 0:00 /usr/bin/bluetooth-applet
2765 ? S 0:00 volumeicon
2767 ? Ssl 0:00 /usr/lib/bonobo/bonobo-activation-server
--ac-activate --ior-output-fd=20
2768 ? S 0:00 /usr/lib/gdu-notification-daemon
2819 ? S 0:01 tint2
2820 ? Ss 0:05 /usr/bin/gnome-screensaver
2826 ? S 0:00 /usr/bin/gnome-keyring-daemon --start
--foreground --components=secrets
to have these guys starting properly due to them needing certain things
to start correctly(keep in mind this is a work in progress, so there is
things wrong)
Justin P. Mattock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/28/2010 04:34 PM, Justin P. Mattock wrote:
> On 12/28/2010 06:59 AM, Dominick Grift wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12/28/2010 03:50 PM, Justin Mattock wrote:
>>> Hello,
>>> I've a strange issue over here, when enforcement mode
>>> bluetooth-applet will not
>>> show up, but after waking from suspend it does.. any ideas on
>>> what/where is causing
>>> this to do so?
>>
>> Judging from the .service files entries in the logs below i suspect you
>> are using Fedora rawhide here or a custom os based off of fedora rawhide?
>>
>
> neither.. just a from scratch system(used the guides here and there on
> packages, but mostly went my own way)
>
>> In either case you can probably do the usual troubleshooting to narrow
>> things down a bit:
>>
>> 1. is this issue even selinux related; e.g. does it work in permissive
>> mode.
>>
>
> works fine under permissive, as soon as enforcement the applet just
> doesnt show up(under ps aux, it is starting)but after waking from S2R
> the applet shows up(strange!!)
If it works fine in permissive mode but not in enforcing mode then it
looks like an SELinux policy issue:
Thus we need AVC denials to see where it is denied access to what it
needs to do. So look for AVC denials and if no AVC denials show up, then
run semodule -DB to remove the dontaudit rules and after that try to
reproduce this issue and check for AVC denials again. When done testing
rebuild the policy with dontaudit rules included by running semodule -B
Please enclose any AVC denials you are seeing that could be related to
your issue.
>> = if selinux related issue (works in permissive mode); are there any avc
>> denials?
>>
>> == if no avc denials use semodule -DB to unload "hidden denial rules"
>> then reproduce.
>>
>> === if avc denials: enclose and/or analyse
>>
>
> yeah I've checked all of those(was thinking it's RFKILL related, but
> then maybe it's not)I'll look again to see..
>
>> If its not an selinux issue may be a setuid/getgid / capability issue?
>>
>
> could be...maybe what I did below, is the cause of this:
>
> Using gdm + fluxbox + gnome-keyring there was some issues with the whole
> session thing.. long story short I ended up adding:(taken from:
> https://bbs.archlinux.org/viewtopic.php?id=67959)
>
> # launches a session dbus instance
> dbuslaunch="`which dbus-launch 2>/dev/null`"
> if [ -n "$dbuslaunch" ] && [ -x "$dbuslaunch" ] && [ -z
> "$DBUS_SESSION_BUS_ADDRESS" ]; then
> eval `$dbuslaunch --sh-syntax --exit-with-session`
> fi
>
> in: /etc/gnome/gdm/Xsession
> and also adding:
> /usr/share/xsessions/fluxbox.desktop
> Exec=ck-launch-session /usr/bin/startfluxbox
>
>
>
> 2656 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --daemonize
> --login
> 2725 ? Ss 0:00 ck-launch-session /usr/bin/startfluxbox
> 2746 ? S 0:00 /usr/bin/dbus-launch --sh-syntax
> --exit-with-session
> 2753 ? Ss 0:00 /usr/bin/ssh-agent -- ck-launch-session
> /usr/bin/startfluxbox
> 2758 ? S 0:04 /usr/bin/fluxbox
> 2760 ? S 0:00 sh /home/justin/.fluxbox/startup
> 2761 ? Sl 0:00 /usr/bin/gnome-power-manager
> 2763 ? SLl 0:00 nm-applet --sm-disable
> 2764 ? S 0:00 /usr/bin/bluetooth-applet
> 2765 ? S 0:00 volumeicon
> 2767 ? Ssl 0:00 /usr/lib/bonobo/bonobo-activation-server
> --ac-activate --ior-output-fd=20
> 2768 ? S 0:00 /usr/lib/gdu-notification-daemon
> 2819 ? S 0:01 tint2
> 2820 ? Ss 0:05 /usr/bin/gnome-screensaver
> 2826 ? S 0:00 /usr/bin/gnome-keyring-daemon --start
> --foreground --components=secrets
>
> to have these guys starting properly due to them needing certain things
> to start correctly(keep in mind this is a work in progress, so there is
> things wrong)
>
> Justin P. Mattock
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0aBPUACgkQMlxVo39jgT/uTQCglwpkgwD5JN895/2WjnNDFVli
Dh4AoIXEIP3fhOTMc06GZSX8xAVv1Bzy
=U+Tw
-----END PGP SIGNATURE-----
>
> If it works fine in permissive mode but not in enforcing mode then it
> looks like an SELinux policy issue:
>
> Thus we need AVC denials to see where it is denied access to what it
> needs to do. So look for AVC denials and if no AVC denials show up, then
> run semodule -DB to remove the dontaudit rules and after that try to
> reproduce this issue and check for AVC denials again. When done testing
> rebuild the policy with dontaudit rules included by running semodule -B
>
> Please enclose any AVC denials you are seeing that could be related to
> your issue.
>
yeah nothing is showing up in the logs i.g.
/var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
semodule -DB has already been done)
Justin P. Mattock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/28/2010 05:35 PM, Justin P. Mattock wrote:
>
>>
>> If it works fine in permissive mode but not in enforcing mode then it
>> looks like an SELinux policy issue:
>>
>> Thus we need AVC denials to see where it is denied access to what it
>> needs to do. So look for AVC denials and if no AVC denials show up, then
>> run semodule -DB to remove the dontaudit rules and after that try to
>> reproduce this issue and check for AVC denials again. When done testing
>> rebuild the policy with dontaudit rules included by running semodule -B
>>
>> Please enclose any AVC denials you are seeing that could be related to
>> your issue.
>>
>
> yeah nothing is showing up in the logs i.g.
> /var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
> semodule -DB has already been done)
strange indeed becuase if it works in permissive mode but not in
enforcing mode then i would suspect its selinux preventing access. In
that case avc denials *should* be visible. either in dmesg ,
/var/log/messages /var/log/xorg.log /var/log/audit/audit.log etc.
>
> Justin P. Mattock
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0aEsEACgkQMlxVo39jgT9vUACgmhUYTFfBoQVMG3+c5V/tgRm4
RWMAoKTc0OFCQyi0OKIwWOK+k80Pe+qX
=5jTw
-----END PGP SIGNATURE-----
On 12/28/2010 08:39 AM, Dominick Grift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/28/2010 05:35 PM, Justin P. Mattock wrote:
>>
>>>
>>> If it works fine in permissive mode but not in enforcing mode then it
>>> looks like an SELinux policy issue:
>>>
>>> Thus we need AVC denials to see where it is denied access to what it
>>> needs to do. So look for AVC denials and if no AVC denials show up, then
>>> run semodule -DB to remove the dontaudit rules and after that try to
>>> reproduce this issue and check for AVC denials again. When done testing
>>> rebuild the policy with dontaudit rules included by running semodule -B
>>>
>>> Please enclose any AVC denials you are seeing that could be related to
>>> your issue.
>>>
>>
>> yeah nothing is showing up in the logs i.g.
>> /var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
>> semodule -DB has already been done)
>
> strange indeed becuase if it works in permissive mode but not in
> enforcing mode then i would suspect its selinux preventing access. In
> that case avc denials *should* be visible. either in dmesg ,
> /var/log/messages /var/log/xorg.log /var/log/audit/audit.log etc.
>
yeah thats the messd up part..(even after waking up from S2R everything
is running as it should i.e. preference panel, etc..)
maybe the RFKILL warning is more than what it is
Justin P. Mattock
On 12/28/2010 10:39 AM, Dominick Grift wrote:
>> yeah nothing is showing up in the logs i.g.
>> /var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
>> semodule -DB has already been done)
> strange indeed becuase if it works in permissive mode but not in
> enforcing mode then i would suspect its selinux preventing access. In
> that case avc denials *should* be visible. either in dmesg ,
> /var/log/messages /var/log/xorg.log /var/log/audit/audit.log etc.
It might be instructive to see if there are any denials when running in
permissive mode. I've encountered situations in the past where no
denials would be reported when running enforcing (even with semodule
-DB, other than the expected dontaudits, of course), yet when running in
permissive mode, there would be denials out the wazzoo, even with apps
that were supposedly not selinux-aware.
Later,
Chris
On 12/28/2010 11:23 AM, Chris Richards wrote:
> On 12/28/2010 10:39 AM, Dominick Grift wrote:
>>> yeah nothing is showing up in the logs i.g.
>>> /var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
>>> semodule -DB has already been done)
>> strange indeed becuase if it works in permissive mode but not in
>> enforcing mode then i would suspect its selinux preventing access. In
>> that case avc denials *should* be visible. either in dmesg ,
>> /var/log/messages /var/log/xorg.log /var/log/audit/audit.log etc.
> It might be instructive to see if there are any denials when running in
> permissive mode. I've encountered situations in the past where no
> denials would be reported when running enforcing (even with semodule
> -DB, other than the expected dontaudits, of course), yet when running in
> permissive mode, there would be denials out the wazzoo, even with apps
> that were supposedly not selinux-aware.
>
> Later,
> Chris
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
yeah those avc's can be little buggers if hidden away in some file
somewhere..I'll have a look again to make sure.. in the meantime
I am noticing in .xsession-errors in enforcing mode:
cat .xsession-errors
/etc/gnome/gdm/Xsession: Beginning session setup...
/etc/gnome/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent --
ck-launch-session /usr/bin/startfluxbox
** (bluetooth-applet:2786): WARNING **: Could not open RFKILL control
device, please verify your installation
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
will not be saved or shared with other applications.
tint2 : nb monitor 1, nb monitor used 1, nb desktop 4
tint2 : pixmap background detection failed
Error changing to home directory /root: Permission denied
Error changing to home directory /root: Permission denied
Error changing to home directory /root: Permission denied
the: Error changing to home directory /root: Permission denied
does not occur in permissive mode so maybe this is whats hitting and
causing the stuckage or something.. I'll need to look again at
everything to make sure I didnt forget a build flag or something
Justin P. Mattock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/28/2010 03:09 PM, Justin P. Mattock wrote:
> On 12/28/2010 11:23 AM, Chris Richards wrote:
>> On 12/28/2010 10:39 AM, Dominick Grift wrote:
>>>> yeah nothing is showing up in the logs i.g.
>>>> /var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
>>>> semodule -DB has already been done)
>>> strange indeed becuase if it works in permissive mode but not in
>>> enforcing mode then i would suspect its selinux preventing access. In
>>> that case avc denials *should* be visible. either in dmesg ,
>>> /var/log/messages /var/log/xorg.log /var/log/audit/audit.log etc.
>> It might be instructive to see if there are any denials when running in
>> permissive mode. I've encountered situations in the past where no
>> denials would be reported when running enforcing (even with semodule
>> -DB, other than the expected dontaudits, of course), yet when running in
>> permissive mode, there would be denials out the wazzoo, even with apps
>> that were supposedly not selinux-aware.
>>
>> Later,
>> Chris
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>
>
>
> yeah those avc's can be little buggers if hidden away in some file
> somewhere..I'll have a look again to make sure.. in the meantime
> I am noticing in .xsession-errors in enforcing mode:
>
>
> cat .xsession-errors
> /etc/gnome/gdm/Xsession: Beginning session setup...
> /etc/gnome/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent --
> ck-launch-session /usr/bin/startfluxbox
>
> ** (bluetooth-applet:2786): WARNING **: Could not open RFKILL control
> device, please verify your installation
> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
> will not be saved or shared with other applications.
> tint2 : nb monitor 1, nb monitor used 1, nb desktop 4
> tint2 : pixmap background detection failed
> Error changing to home directory /root: Permission denied
> Error changing to home directory /root: Permission denied
> Error changing to home directory /root: Permission denied
>
>
> the: Error changing to home directory /root: Permission denied
> does not occur in permissive mode so maybe this is whats hitting and
> causing the stuckage or something.. I'll need to look again at
> everything to make sure I didnt forget a build flag or something
>
> Justin P. Mattock
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
Are you logging in as root via X?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0dsFAACgkQrlYvE4MpobOe1gCfRq1Ygy/8bkXOhdY/iEC1PWu0
pIkAn1ZDOgjSQHuuwGMOyrEZYDcyvF++
=99dW
-----END PGP SIGNATURE-----
On 12/31/2010 02:28 AM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/28/2010 03:09 PM, Justin P. Mattock wrote:
>> On 12/28/2010 11:23 AM, Chris Richards wrote:
>>> On 12/28/2010 10:39 AM, Dominick Grift wrote:
>>>>> yeah nothing is showing up in the logs i.g.
>>>>> /var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
>>>>> semodule -DB has already been done)
>>>> strange indeed becuase if it works in permissive mode but not in
>>>> enforcing mode then i would suspect its selinux preventing access. In
>>>> that case avc denials *should* be visible. either in dmesg ,
>>>> /var/log/messages /var/log/xorg.log /var/log/audit/audit.log etc.
>>> It might be instructive to see if there are any denials when running in
>>> permissive mode. I've encountered situations in the past where no
>>> denials would be reported when running enforcing (even with semodule
>>> -DB, other than the expected dontaudits, of course), yet when running in
>>> permissive mode, there would be denials out the wazzoo, even with apps
>>> that were supposedly not selinux-aware.
>>>
>>> Later,
>>> Chris
>>> _______________________________________________
>>> refpolicy mailing list
>>> refpolicy at oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>
>>
>>
>> yeah those avc's can be little buggers if hidden away in some file
>> somewhere..I'll have a look again to make sure.. in the meantime
>> I am noticing in .xsession-errors in enforcing mode:
>>
>>
>> cat .xsession-errors
>> /etc/gnome/gdm/Xsession: Beginning session setup...
>> /etc/gnome/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent --
>> ck-launch-session /usr/bin/startfluxbox
>>
>> ** (bluetooth-applet:2786): WARNING **: Could not open RFKILL control
>> device, please verify your installation
>> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
>> will not be saved or shared with other applications.
>> tint2 : nb monitor 1, nb monitor used 1, nb desktop 4
>> tint2 : pixmap background detection failed
>> Error changing to home directory /root: Permission denied
>> Error changing to home directory /root: Permission denied
>> Error changing to home directory /root: Permission denied
>>
>>
>> the: Error changing to home directory /root: Permission denied
>> does not occur in permissive mode so maybe this is whats hitting and
>> causing the stuckage or something.. I'll need to look again at
>> everything to make sure I didnt forget a build flag or something
>>
>> Justin P. Mattock
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
> Are you logging in as root via X?
no I dont think I was(under ps auxZ everything showed the proper user
from what I remembered(gdm))
Keep in mind one thing I didnt mention(and didnt think was the cause)is
Im seeing pkexec showing up in dmesg.. I can supply the avc for that,
but might be a while due to having to compress that system and ready the
machine to be sold(no job, no money, no food etc...)
I'll keep you updated with this, as soon as I connect the dots with
other things..
Justin P. Mattock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/03/2011 08:29 PM, Justin P. Mattock wrote:
> On 12/31/2010 02:28 AM, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12/28/2010 03:09 PM, Justin P. Mattock wrote:
>>> On 12/28/2010 11:23 AM, Chris Richards wrote:
>>>> On 12/28/2010 10:39 AM, Dominick Grift wrote:
>>>>>> yeah nothing is showing up in the logs i.g.
>>>>>> /var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
>>>>>> semodule -DB has already been done)
>>>>> strange indeed becuase if it works in permissive mode but not in
>>>>> enforcing mode then i would suspect its selinux preventing access. In
>>>>> that case avc denials *should* be visible. either in dmesg ,
>>>>> /var/log/messages /var/log/xorg.log /var/log/audit/audit.log etc.
>>>> It might be instructive to see if there are any denials when running in
>>>> permissive mode. I've encountered situations in the past where no
>>>> denials would be reported when running enforcing (even with semodule
>>>> -DB, other than the expected dontaudits, of course), yet when
>>>> running in
>>>> permissive mode, there would be denials out the wazzoo, even with apps
>>>> that were supposedly not selinux-aware.
>>>>
>>>> Later,
>>>> Chris
>>>> _______________________________________________
>>>> refpolicy mailing list
>>>> refpolicy at oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>>
>>>
>>>
>>> yeah those avc's can be little buggers if hidden away in some file
>>> somewhere..I'll have a look again to make sure.. in the meantime
>>> I am noticing in .xsession-errors in enforcing mode:
>>>
>>>
>>> cat .xsession-errors
>>> /etc/gnome/gdm/Xsession: Beginning session setup...
>>> /etc/gnome/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent --
>>> ck-launch-session /usr/bin/startfluxbox
>>>
>>> ** (bluetooth-applet:2786): WARNING **: Could not open RFKILL control
>>> device, please verify your installation
>>> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
>>> will not be saved or shared with other applications.
>>> tint2 : nb monitor 1, nb monitor used 1, nb desktop 4
>>> tint2 : pixmap background detection failed
>>> Error changing to home directory /root: Permission denied
>>> Error changing to home directory /root: Permission denied
>>> Error changing to home directory /root: Permission denied
>>>
>>>
>>> the: Error changing to home directory /root: Permission denied
>>> does not occur in permissive mode so maybe this is whats hitting and
>>> causing the stuckage or something.. I'll need to look again at
>>> everything to make sure I didnt forget a build flag or something
>>>
>>> Justin P. Mattock
>>> _______________________________________________
>>> refpolicy mailing list
>>> refpolicy at oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>> Are you logging in as root via X?
>
>
> no I dont think I was(under ps auxZ everything showed the proper user
> from what I remembered(gdm))
>
> Keep in mind one thing I didnt mention(and didnt think was the cause)is
> Im seeing pkexec showing up in dmesg.. I can supply the avc for that,
> but might be a while due to having to compress that system and ready the
> machine to be sold(no job, no money, no food etc...)
>
> I'll keep you updated with this, as soon as I connect the dots with
> other things..
>
> Justin P. Mattock
>
>
Well there is an open bug against gnome-power-manager launching
gnome-screensaver when run from gdm. But I would figure this would do
some wierd stuff in gdm home dir not /root
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jKVEACgkQrlYvE4MpobMdUgCgtNrGaoa7JancnUhVJrJmi33i
8R0AnA9EMUqcBEQ4mIgGEFUBaqr/ssmR
=oRBV
-----END PGP SIGNATURE-----
On 01/04/2011 06:06 AM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/03/2011 08:29 PM, Justin P. Mattock wrote:
>> On 12/31/2010 02:28 AM, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 12/28/2010 03:09 PM, Justin P. Mattock wrote:
>>>> On 12/28/2010 11:23 AM, Chris Richards wrote:
>>>>> On 12/28/2010 10:39 AM, Dominick Grift wrote:
>>>>>>> yeah nothing is showing up in the logs i.g.
>>>>>>> /var/log/Xorg,messages,user.log, etc...(no audit daemon running), and
>>>>>>> semodule -DB has already been done)
>>>>>> strange indeed becuase if it works in permissive mode but not in
>>>>>> enforcing mode then i would suspect its selinux preventing access. In
>>>>>> that case avc denials *should* be visible. either in dmesg ,
>>>>>> /var/log/messages /var/log/xorg.log /var/log/audit/audit.log etc.
>>>>> It might be instructive to see if there are any denials when running in
>>>>> permissive mode. I've encountered situations in the past where no
>>>>> denials would be reported when running enforcing (even with semodule
>>>>> -DB, other than the expected dontaudits, of course), yet when
>>>>> running in
>>>>> permissive mode, there would be denials out the wazzoo, even with apps
>>>>> that were supposedly not selinux-aware.
>>>>>
>>>>> Later,
>>>>> Chris
>>>>> _______________________________________________
>>>>> refpolicy mailing list
>>>>> refpolicy at oss.tresys.com
>>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>>>
>>>>
>>>>
>>>> yeah those avc's can be little buggers if hidden away in some file
>>>> somewhere..I'll have a look again to make sure.. in the meantime
>>>> I am noticing in .xsession-errors in enforcing mode:
>>>>
>>>>
>>>> cat .xsession-errors
>>>> /etc/gnome/gdm/Xsession: Beginning session setup...
>>>> /etc/gnome/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent --
>>>> ck-launch-session /usr/bin/startfluxbox
>>>>
>>>> ** (bluetooth-applet:2786): WARNING **: Could not open RFKILL control
>>>> device, please verify your installation
>>>> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
>>>> will not be saved or shared with other applications.
>>>> tint2 : nb monitor 1, nb monitor used 1, nb desktop 4
>>>> tint2 : pixmap background detection failed
>>>> Error changing to home directory /root: Permission denied
>>>> Error changing to home directory /root: Permission denied
>>>> Error changing to home directory /root: Permission denied
>>>>
>>>>
>>>> the: Error changing to home directory /root: Permission denied
>>>> does not occur in permissive mode so maybe this is whats hitting and
>>>> causing the stuckage or something.. I'll need to look again at
>>>> everything to make sure I didnt forget a build flag or something
>>>>
>>>> Justin P. Mattock
>>>> _______________________________________________
>>>> refpolicy mailing list
>>>> refpolicy at oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>> Are you logging in as root via X?
>>
>>
>> no I dont think I was(under ps auxZ everything showed the proper user
>> from what I remembered(gdm))
>>
>> Keep in mind one thing I didnt mention(and didnt think was the cause)is
>> Im seeing pkexec showing up in dmesg.. I can supply the avc for that,
>> but might be a while due to having to compress that system and ready the
>> machine to be sold(no job, no money, no food etc...)
>>
>> I'll keep you updated with this, as soon as I connect the dots with
>> other things..
>>
>> Justin P. Mattock
>>
>>
> Well there is an open bug against gnome-power-manager launching
> gnome-screensaver when run from gdm. But I would figure this would do
> some wierd stuff in gdm home dir not /root
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0jKVEACgkQrlYvE4MpobMdUgCgtNrGaoa7JancnUhVJrJmi33i
> 8R0AnA9EMUqcBEQ4mIgGEFUBaqr/ssmR
> =oRBV
> -----END PGP SIGNATURE-----
>
yeah that's what's getting me on this, is the pkexec is something to do
with the backlight dimmer helper thing(loading nouvea revealed this one)
strange thing with the bluetooth-applet is after waking up from suspend
the applet will show right up in the dock with nm-applet/gnome-power
like nothing ever happened.
in regards to the policy, my build.conf looks like this:
TYPE = mcs
NAME = refpolicy
UNK_PERMS = deny
DIRECT_INITRC = n
MONOLITHIC = n
UBAC = y
MLS_SENS = 16
MLS_CATS = 256
MCS_CATS = 256
QUIET = n
only thing not used with this system is the DISTRO switch since it is a
custom clfs build.
Justin P. Mattock