LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-27-2016, 06:39 PM   #76
BW-userx
LQ Guru
 
Registered: Sep 2013
Location: MID-SOUTH USA
Distribution: Slackware 14.2 / Slackware 14.2 current / Manjaro / Parrot
Posts: 6,873

Original Poster
Rep: Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387

Quote:
Originally Posted by bassmadrigal View Post
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 ...

Last edited by BW-userx; 12-27-2016 at 06:45 PM.
 
Old 12-27-2016, 11:49 PM   #77
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,515

Rep: Reputation: Disabled
Quote:
Originally Posted by BW-userx View Post
@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.

Last edited by Didier Spaier; 12-28-2016 at 02:21 AM.
 
Old 12-28-2016, 06:23 AM   #78
BW-userx
LQ Guru
 
Registered: Sep 2013
Location: MID-SOUTH USA
Distribution: Slackware 14.2 / Slackware 14.2 current / Manjaro / Parrot
Posts: 6,873

Original Poster
Rep: Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387Reputation: 1387
Quote:
Originally Posted by Didier Spaier View Post
$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

Last edited by BW-userx; 12-28-2016 at 06:30 AM.
 
1 members found this post helpful.
Old 12-28-2016, 06:48 AM   #79
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,515

Rep: Reputation: Disabled
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 View Post
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.

Last edited by Didier Spaier; 12-28-2016 at 07:04 AM.
 
Old 06-13-2018, 02:45 PM   #80
websafe
LQ Newbie
 
Registered: May 2008
Location: Opole, PL
Distribution: Slackware, CentOS
Posts: 15

Rep: Reputation: 1
Cool

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 :-)
 
Old 06-13-2018, 03:24 PM   #81
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,031

Rep: Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408
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.
 
Old 06-14-2018, 10:43 PM   #82
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,031

Rep: Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408Reputation: 1408
As it turns out, after you add a user to the lp group, you must
  1. As root, run /etc/rc.d/rc.messagebus reload (or reboot)
  2. Logout that user
  3. 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.)
 
  


Reply

Tags
bluetoothd


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] DBD::ODBC works as root but not as non-root user on CentOS5 - any ideas? prgupta Red Hat 2 07-13-2010 12:20 AM
Gnome Bluetooth applet in Lenny: root user vs. ordinary user SuSE_Lamer Linux - Desktop 1 03-20-2009 05:41 AM
Gnome Bluetooth applet in Lenny: root user vs. ordinary user SuSE_Lamer Debian 1 02-25-2009 01:30 AM
IntelliMouse thumb buttons work as root, broken as non-root user, wheel works always digital vortex Linux - Hardware 7 03-02-2004 04:14 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:35 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration