[SOLVED] Bluetooth works in root but not user

BW-userx · 12-27-2016, 06:39 PM

Quote:

Originally Posted by bassmadrigal

I rarely use xfce, so I'm not sure with this, but... my first guess is that there was something misconfigured or enabled/disabled in your system and you changed that around the time you set up your user with sudo. A second (albeit, less likely in my book) guess is that xfce will attempt to detect if your user is a member of the wheel group and if so, provide you a shut down/reboot option. But this does not seem to be a very smart idea because: 1. Just because a user is assigned wheel, doesn't mean that wheel has the ability to reboot the system (depending on how you have it set up in /etc/sudoers). 2. Depending on how /etc/sudoers is set up, you may need to type a password to even use sudo, so xfce would need to pop up a dialog to accept said password. 3. As said above, wheel doesn't have to be wheel. You can have full access to all commands with sudo by just setting up your user to have access within /etc/sudoers, not needing to ever use the wheel group. Or you could have a completely separate group called reboot that you set up in /etc/sudoers to have the ability to run the reboot, shutdown, and halt commands.

With the flexibility of Linux, sudo, and xfce, I find it hard to believe that they set up their DE to only detect the wheel group and then to present the user shutdown/reboot options. However, developers sometimes do things that I don't understand, so it is still possible they have this. All I know is KDE (my preferred DE) is able to reboot/shutdown without needing sudo and without requiring a user to be in the wheel group. Maybe if I get a chance over the next week, I can try creating a new user and see what I'm present with when logging into xfce.

I understand how the sudoer file can be detailed to specific tasks per how every or whatever group name that is added to or modify within that file. I've just never had to do this to experience it.

Not having dug into the why behind everything Linux does. I just use the obvious that I see when it works for me unless I have had to dig into a situation that needed an added file(s) or modification to get something to work.

I've always seen in whichever Distro I've ever tried have this same effect with Xfce so I just assumed ... but that is what one gets for assuming.

I stand down already.

As you and I have stated it maybe somewhere within how xfce is set up to do this task. I too have used distro's that use the sudo group instead of wheel that got me that same effect.

A polkit file that states a group a user belongs to in order for something to word. ie. I had to set up a polkit-1 rules file to state if a user is assigned to storage group so that automount will work to get that to work in fluxbox. That is the thing with Linux there is more than one way to skin a cat to get things to work in it.

I do not know what xfce does to get this. I do not care. it is of no consequence to me to bother with it. I am the only user on my laptop, and having it like that works for me.
Point taken ...

Didier Spaier · 12-27-2016, 11:49 PM

Quote:

Originally Posted by BW-userx

@Didier Spaier

I have been looking for a different Distro to take up this space I was using for another one, that I do not want on my Laptop. How does it play with using the same home user directory across different distros?

I have Slackware and Void Linux sharing my same Home user Directory nicely.

$HOME hosts a lot of hidden files and directories, especially configuration of WMs/DE (and Slint does ship default user settings in /etc/skel) and of many apps, that maybe differ between systems. So I favor using a different $HOME for each system and making symlinks on a case by case basis whenever needed. For instance I symlink .gnupg and .purple across systems. For individual files (not directories) maybe you could use hard links instead, I didn't try.

But if you want to access common data like documents, videos, photos, you could share a specific directory called e.g. /home/shared in all systems, provided that you use the same login name that own /home/shared. I do not have dedicated partitions mounted as /home but you could set a up a single partition that you would mount as /home/shared in all systems.

BW-userx · 12-28-2016, 06:23 AM

Quote:

Originally Posted by Didier Spaier

$HOME hosts a lot of hidden files and directories, especially configuration of WMs/DE (and Slint does ship default user settings in /etc/skel) and of many apps, that maybe differ between systems. So I favor using a different $HOME for each system and making symlinks on a case by case basis whenever needed. For instance I symlink .gnupg and .purple across systems. For individual files (not directories) maybe you could use hard links instead, I didn't try.

YEP as Debian gets confused when trying to share a $HOME with another Linux System, same user account.
Because I am the only one using this Laptop I find it easier to do set up like this instead of using links, as I find myself reinstalling a distro from time to time. It is quicker to just add the same /home do not format, and add the user name, ensure the GID is the same for both systems. This setup Xfce4 to be the same setup regardless of which OS I am using at the time. Between Slackware and Void Linux. the only hindrance is if the plugins are missing for one of the systems. For Fluxbox it is now hiding its conf directory within a separate folder, not using .xinitrc it uses a startup file within its .fluxbox directory. therefore removing the .xinitrc from interfering with other WM/DT in more than one Linux OS.

Slackware can be set up to use startx or a GUI login, the startx uses the .xinitrc but fluxbox no longer does. If it did before. For reasons stated above.

same goes for VOID Linux in regards to Fluxbox. The .xinitrc or other hidden files used to configure software or the desktop. In my use I pretty much keep both systems about the same in what I have installed in them to use. The terminals would be the exception. Slackware only has what it came with in the original install. There is no real conflict there, if it has it in the app menu but not installed (Fluxbox) then it just does not start. oops, pick a different terminal. Keyboard shortcuts to help to eliminate that possibility.

as far as .bashrc I want them to be the same. Everything is the same setup in both Systems. that is how I want it.
Sound familiar?

Quote:

But if you want to access common data like documents, videos, photos, you could share a specific directory called e.g. /home/shared in all systems, provided that you use the same login name that own /home/shared. I do not have dedicated partitions mounted as /home but you could set a up a single partition that you would mount as /home/shared in all systems.

I do keep a shared partition in fstab on one of my hard drives for everything, other stuff for whatever reason my brain leads me to do so. it is a case by case basis event.

Well, there is only one way to find out. That is by installing your endeavor onto my Laptop and prepare for damage control, just in case.

it will be a good opportunity for you too. To find out more about what your system is capable of.

I'll let you know.

never mind about what I said on dd. I just made a first glance option.As I am sure you already have dismissed my suggestion on grounds of this page I just found.

http://slint.fr/wiki/en/installation

Didier Spaier · 12-28-2016, 06:48 AM

About fluxbox: yes its behavior is specific as /usr/bin/startfluxbox actually writes ~/.fluxbox/startup (only if not already there), then starts it. Anyway every WM has more or less its own way with respect to startup. For instance I ended up writing a startup script /usr/bin/starttwm for twm whose source tarball does not include one as you can see here.

Quote:

Originally Posted by BW-userx

Well, there is only one way to find out. That is by installing your endeavor onto my Laptop and prepare for damage control, just in case.

it will be a good opportunity for you too. To find out more about what your system is capable of.

I'll let you know.

Yes, please do.

Quote:

never mind about what I said on dd. I just made a first glance option.As I am sure you already have dismissed my suggestion ...

No, I didn't. If you find the information hard to find, others will as well. And what would be the point of requesting feedback then ignore it?

Thanks for your remarks.

websafe · 06-13-2018, 02:45 PM

I had the exactly same problem. A fresh Slackware64 14.2 installation.
Bluetooth Manager (blueman-manager) was working fine as root,
but as a normal user it wouldn't start.

Running `blueman-manager` or `blueman-applet` from the console
showed some ~ "dbus access denied" errors...

Then I found this: https://bugs.debian.org/cgi-bin/bugr...cgi?bug=736744

The solution is simple:

1) In /etc/dbus-1/system.d/bluetooth.conf find this:

Code:

 <policy at_console="true">
    <allow send_destination="org.bluez"/>
  </policy>

and replace true with false:

Code:

 <policy at_console="false">
    <allow send_destination="org.bluez"/>
  </policy>

2) Reboot.

Now the Bluetooth manager should work as expected on
a normal (non-root) user account the same way it worked
on the root account.

The "normal user" doesn't need to be in any "fancy" groups,
I'm testing now without all these additional groups
and it works, because that's not a group permission problem,
it's a "dbus permission problem", whatever this means ;-)

Code:

bash-4.3$ groups
users

Of course adding the user to lp,floppy,audio,video,cdrom,plugdev,power,netdev,scanner
makes sense and is sometimes required but it's not relevant to the
Bluetooth Manager / Applet problem for non-root users, because they work without
these groups, only /etc/dbus-1/system.d/bluetooth.conf
needs to be modified as mentioned above.

Peace and love :-)

Richard Cranium · 06-13-2018, 03:24 PM

If you add your user to the lp group, you won't have to modify that file. That's why it's relevant to the bluetooth issue.

Richard Cranium · 06-14-2018, 10:43 PM

As it turns out, after you add a user to the lp group, you must

As root, run /etc/rc.d/rc.messagebus reload (or reboot)
Logout that user
Log in with that user

I just tested that sequence on my laptop with new users. (Don't run /etc/rc.d/rc.messagebus restart for you will have to restart bluetooth, NetworkManager, and any desktop environment that you've got running. As I found out.)

louigi600 · 01-16-2021, 04:05 PM

Sorry to bounce on this solved issue ... but 18 months have gone by but the problem is still there. It took me a while before I was able to find this thread.
Is there a reason for not having a fix for this in the patches ?

bassmadrigal · 01-16-2021, 05:55 PM

Quote:

Originally Posted by louigi600

Sorry to bounce on this solved issue ... but 18 months have gone by but the problem is still there. It took me a while before I was able to find this thread.
Is there a reason for not having a fix for this in the patches ?

What needed a fix? The original issue was solved by fixing OP's assigned groups and assigning them to the recommended defaults for Slackware (the ones that the adduser script prompts users to add).

But I'll admit, there is a lot to digest in this thread, so if it is something else that needs to be patched, can you remind us.

louigi600 · 01-17-2021, 02:28 AM

Apart from the groups it is still necessary to edit /etc/dbus-1/system.d/bluetooth.conf and change the "policy at_console" from true to false else it still will not work:

Code:

<policy at_console="false">
    <allow send_destination="org.bluez"/>
  </policy>

bassmadrigal · 01-17-2021, 11:09 AM

But that change isn't needed. Your comment is the first in these 80+ posts suggesting a change to that portion of that conf file.

Bluetooth works fine on my system as long as I'm in the lp and plugdev groups. Can you point to some posts that suggest that change? I'd be interesting on reading up on the issue and potential solution.

louigi600 · 01-17-2021, 12:57 PM

Well I had to change that to be able to use it from non root user (with all the groups added) without sudo). I had tried everything else and only when I changed that last thing did it start working from normal user.

bassmadrigal · 01-17-2021, 01:04 PM

Had you logged out and logged back in? If you add your user to those groups, it won't take effect without logging out and logging back in (unless you reload the groups somehow... I think there's a way, but I don't remember what the command is).

Nothing should be required to get bluetooth running once a user belongs to the lp and plugdev groups (in reality, only the lp group is used for bluetooth, but the plugdev group is needed for some bluetooth adapters).

louigi600 · 01-17-2021, 01:30 PM

Yes ... and I cant be the only one: websafe must have had the same thing otherwise he would not have posted the mod to /etc/dbus-1/system.d/bluetooth.conf

Code:

davide@nuc8i5:~$ grep "policy at_console" /etc/dbus-1/system.d/bluetooth.conf
<!--  <policy at_console="true"> -->
  <policy at_console="false">
davide@nuc8i5:~$ id
uid=1000(davide) gid=1000(davide) groups=1000(davide),7(lp),10(wheel),11(floppy),16(dialout),17(audio),18(video),19(cdrom),83(plugdev),84(power),86(netdev),87(polkitd),93(scanner),100(users)
davide@nuc8i5:~$ blueman-manager

that produces a normal start of blueman-manager.
If I put it like before:

Code:

davide@nuc8i5:~$ grep "policy at_console" /etc/dbus-1/system.d/bluetooth.conf
  <policy at_console="true"> 
<!--  <policy at_console="false"> -->
davide@nuc8i5:~$ blueman-manager 
_________
Load (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:60)
['PulseAudioProfile', 'Services'] 
_________
__load_plugin (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:133)
loading <class 'blueman.plugins.manager.Services.Services'> 
_________
__load_plugin (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:133)
loading <class 'blueman.plugins.manager.PulseAudioProfile.PulseAudioProfile'> 
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
1 
blueman-manager version 2.0.6 starting
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
2 
_________
on_bluez_name_owner_changed (/usr/bin/blueman-manager:96)
org.bluez owner changed to  :1.0 
ERROR:dbus.proxies:Introspect error on :1.0:/: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.40" (uid=1000 pid=4673 comm="/usr/bin/python2.7 /usr/bin/blueman-manager ") interface="org.freedesktop.DBus.Introspectable" member

bassmadrigal · 01-17-2021, 06:11 PM

I'm not seeing the same issue on my 14.2 install:

Code:

jbhansen@craven-moorhead:~$ grep "policy at_console" /etc/dbus-1/system.d/bluetooth.conf 
  <policy at_console="true">
jbhansen@craven-moorhead:~$ groups
users lp floppy audio video cdrom plugdev power netdev scanner vboxusers vpn
jbhansen@craven-moorhead:~$ blueman-manager 
_________
Load (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:60)
['Services', 'PulseAudioProfile'] 
_________
__load_plugin (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:133)
loading <class 'blueman.plugins.manager.Services.Services'> 
_________
__load_plugin (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:133)
loading <class 'blueman.plugins.manager.PulseAudioProfile.PulseAudioProfile'> 
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
1 
blueman-manager version 2.0.6 starting
Stale PID, overwriting
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
2 
_________
on_bluez_name_owner_changed (/usr/bin/blueman-manager:96)
org.bluez owner changed to  :1.0 
_________
get_interface_version (/usr/lib64/python2.7/site-packages/blueman/bluez/BlueZInterface.py:13)
Detected BlueZ 5 
_________
SetAdapter (/usr/lib64/python2.7/site-packages/blueman/gui/DeviceList.py:271)
 
_________
on_adapter_changed (/usr/lib64/python2.7/site-packages/blueman/gui/manager/ManagerToolbar.py:83)
toolbar adapter /org/bluez/hci0 
_________
__init__ (/usr/lib64/python2.7/site-packages/blueman/main/Device.py:26)
caching initial properties 
_________
add_device (/usr/lib64/python2.7/site-packages/blueman/gui/DeviceList.py:317)
adding new device 
_________
do_cache (/usr/lib64/python2.7/site-packages/blueman/gui/DeviceList.py:496)
Caching new device B4:F1:DA:66:39:AB 
_________
row_update_event (/usr/lib64/python2.7/site-packages/blueman/gui/manager/ManagerDeviceList.py:264)
row update event Fake False 
_________
row_update_event (/usr/lib64/python2.7/site-packages/blueman/gui/manager/ManagerDeviceList.py:264)
row update event Trusted 1 
_________
row_update_event (/usr/lib64/python2.7/site-packages/blueman/gui/manager/ManagerDeviceList.py:264)
row update event Paired 1 
_________
Generate (/usr/lib64/python2.7/site-packages/blueman/gui/manager/ManagerDeviceMenu.py:173)
Pixel 2 XL 
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
3 
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
4 
_________
on_pa_ready (/usr/lib64/python2.7/site-packages/blueman/plugins/manager/PulseAudioProfile.py:29)
connected 
_________
<lambda> (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:353)
1

In fact, if I comment out that rule completely and reload the messagebus service, it still works fine.

To check and make sure the reload worked properly, I changed the group to a non-existent group and reloaded the messagebus service. That makes it so I can no longer open bluetooth-manager.

Code:

jbhansen@craven-moorhead:~$ grep -A8 "policy at_console" /etc/dbus-1/system.d/bluetooth.conf 
<!--  <policy at_console="true">
    <allow send_destination="org.bluez"/>
  </policy>-->

  <!-- allow users of lp group (printing subsystem) to 
       communicate with bluetoothd -->
  <policy group="lp1">
    <allow send_destination="org.bluez"/>
  </policy>
jbhansen@craven-moorhead:~$ blueman-manager 
_________
Load (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:60)
['Services', 'PulseAudioProfile'] 
_________
__load_plugin (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:133)
loading <class 'blueman.plugins.manager.Services.Services'> 
_________
__load_plugin (/usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py:133)
loading <class 'blueman.plugins.manager.PulseAudioProfile.PulseAudioProfile'> 
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
1 
blueman-manager version 2.0.6 starting
Stale PID, overwriting
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
2 
_________
on_bluez_name_owner_changed (/usr/bin/blueman-manager:96)
org.bluez owner changed to  :1.0 
ERROR:dbus.proxies:Introspect error on :1.0:/: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.111" (uid=1000 pid=26448 comm="/usr/bin/python2.7 /usr/bin/blueman-manager ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination=":1.0" (uid=0 pid=1750 comm="/usr/sbin/bluetoothd ")
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 604, in msg_reply_handler
    reply_handler(*message.get_args_list(**get_args_opts))
  File "/usr/bin/blueman-manager", line 140, in on_bluez_name_owner_changed
    self.List = ManagerDeviceList(adapter=self.Config["last-adapter"], inst=self)
  File "/usr/lib64/python2.7/site-packages/blueman/gui/manager/ManagerDeviceList.py", line 56, in __init__
    DeviceList.__init__(self, adapter, data)
  File "/usr/lib64/python2.7/site-packages/blueman/gui/DeviceList.py", line 89, in __init__
    self.manager = Bluez.Manager()
  File "/usr/lib64/python2.7/site-packages/blueman/bluez/errors.py", line 148, in warp
    raise parse_dbus_error(exception)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.111" (uid=1000 pid=26448 comm="/usr/bin/python2.7 /usr/bin/blueman-manager ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination=":1.0" (uid=0 pid=1750 comm="/usr/sbin/bluetoothd ")
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
3 
_________
pa_context_event (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:341)
4 
_________
on_pa_ready (/usr/lib64/python2.7/site-packages/blueman/plugins/manager/PulseAudioProfile.py:29)
connected 
_________
<lambda> (/usr/lib64/python2.7/site-packages/blueman/main/PulseAudioUtils.py:353)
1

In playing with several different configurations, the only way I've found to get that access denied message is to not be a part of the group that bluetooth expects you to be a part of (lp on a stock Slackware system).