LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 06-21-2012, 02:59 PM   #1
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,324
Blog Entries: 3

Rep: Reputation: 86
Getting libusb permission errors running sudo commands


Okay, I'll admit it up front. I've done something and have no clue when or what or how.

Something is taking group ownership of USB devices
using the groupname 'plugdev'. Reading around the net tells me this is a hold over from the old hotplug days -- long gone from my Mint-12 with Cinnamon workstation.

Normally, things look like this:
Code:
prompt$ ls -l /dev/bus/usb/001/

total 0
crw-rw-r-- 1 root root 189, 0 2012-06-21 00:19 001
crw-rw-r-- 1 root root 189, 1 2012-06-21 00:19 002
crw-rw-r-- 1 root root 189, 2 2012-06-21 00:19 003
crw-rw-r-- 1 root root 189, 3 2012-06-21 00:19 004
crw-rw-r-- 1 root root 189, 4 2012-06-21 00:19 005
During the failure, things look like this:
Code:
prompt$ ls -l /dev/bus/usb/001/

total 0
crw-rw-r-- 1 root root 189, 0 2012-06-21 00:19 001
crw-rw-r-- 1 root root 189, 1 2012-06-21 00:19 002
crw-rw-r-- 1 root plugdev 189, 2 2012-06-21 00:19 003
crw-rw-r-- 1 root root 189, 3 2012-06-21 00:19 004
crw-rw-r-- 1 root root 189, 4 2012-06-21 00:19 005
Can anyone tell me what to look for and how to resolve this?

I learned about this problem when 'sudo' started complaining every time I used it.

Thanks in advance,
~~~ 0;-Dan
 
Old 06-22-2012, 11:31 AM   #2
Kustom42
Senior Member
 
Registered: Mar 2012
Distribution: Red Hat
Posts: 1,565

Rep: Reputation: 410Reputation: 410Reputation: 410Reputation: 410Reputation: 410
Maybe udev rules??

Check to see if you have anything in: /etc/udev/rules.d/

That might be causing it. but its just a maybe.
 
Old 06-22-2012, 01:47 PM   #3
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,324
Blog Entries: 3

Original Poster
Rep: Reputation: 86
The only thing in /etc/udev/rules.d is a link file: z80_user.rules.
The link targets the actual file, /etc/udev/user.rules.

The actual file is empty.

I searched all of /etc for any text files having the string 'plugdev'.
The only thing found was all of the group, group-shadow and related files
where the 'plugdev' groupname is caused to exist.

I also searched all of /usr for any text files having the string 'plugdev'.
Here there was something dealing with fingerprint reader and camera.

I'm not adding and removing devices -- especially fingerprint or camera --
so I don't know why it would be setting ownership after I remove the plugdev
mess.

I'd hope that the searches would turn up a script or rule or similar text
item that was setting the permission. Since I didn't find one, it must
be in hard code somewhere.

Stumped,
~~~ 0;-Dan
 
Old 06-23-2012, 06:57 AM   #4
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
This may be a red herring and I'm not sure if this will give you answers, but have a look here: http://www.linuxquestions.org/questi...589/page2.html Specifically, the last post on page 2 caught my attention. From doing a little bit of digging, it looks like VFAT and NTFS devices are handled a little bit differently in that settings in fstab are what control the permissions and ownership.

Looking at the last post, the part where it shows, # /etc/fstab: UUID=1234-1234 is making me want to suggest that you also look at the udev rules for insights.
 
Old 06-23-2012, 01:28 PM   #5
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,531
Blog Entries: 27

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
There are also udev rules in /lib/udev/rules.d/ and maybe /dev/.udev/rules.d/

IDK Mint-12 or Cinammon. Is the behaviour illustrated in the OP definitely broken? What are you doing with sudo and what is the error message?
 
Old 06-23-2012, 02:12 PM   #6
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,324
Blog Entries: 3

Original Poster
Rep: Reputation: 86
Here is the typical failure scenario:
  1. ... enough time passed that 'sudo' password has expires ...
  2. use any 'sudo something' command
    Code:
    prompt$ sudo ls -lh /dev/usb
    [sudo] password for username: 
    
    libusb couldn't open USB device /dev/bus/usb/001/003: Permission denied.
    libusb requires write access to USB device nodes.
    
    ls: cannot access /dev/usb: No such file or directory
  3. go look at the path in question
    Code:
    ls -lh /dev/bus/usb/001/*
    crw-rw-r-- 1 root root 189, 0 2012-06-21 00:19 /dev/bus/usb/001/001
    crw-rw-r-- 1 root root 189, 1 2012-06-21 00:19 /dev/bus/usb/001/002
    crw-rw-r-- 1 root plugdev 189, 2 2012-06-21 00:19 /dev/bus/usb/001/003
    crw-rw-r-- 1 root root 189, 3 2012-06-21 00:19 /dev/bus/usb/001/004
    crw-rw-r-- 1 root root 189, 4 2012-06-21 00:19 /dev/bus/usb/001/005

So I use chown to alter the device ownership. The error message stops happening.
After a while, the permission changes again and the cycle repeats.

Thanks,
~~~ 0;-Dan
 
Old 06-24-2012, 06:22 AM   #7
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
This definitely sounds like you changed a mask somewhere, the question is where. Normally, one does not need to manually change the permissions of a plug-able device via sudo chmod as these are handled by the "rules" associated with the daemon process that does the heavy lifting of mounting the media. This area gets confusing because in the last couple of years there has been A LOT of changes to how these things are handled with some methods getting deprecated and even removed. I am not an expert on this area, but it involves HAL, DBUS, PLUGDEG, UDEV, and possibly other systems, some of which may not be used anymore.

The bottom line is that I don't have a definitive answer for you. I would look into what "system" assigns the default permissions for plug-able devices on Mint, or failing that Ubuntu as Mint is a derivative of it. If that isn't leading you anywhere, my next suggestion would to to try some of the IRC channels and see if you can get put in contact with the developers or package maintenance team.
 
Old 06-24-2012, 08:16 PM   #8
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,324
Blog Entries: 3

Original Poster
Rep: Reputation: 86
Quote:
Originally Posted by Noway2 View Post
This definitely sounds like you changed a mask somewhere, the question is where. Normally, one does not need to manually change the permissions of a plug-able device via sudo chmod as these are handled by the "rules" associated with the daemon process that does the heavy lifting of mounting the media. This area gets confusing because in the last couple of years there has been A LOT of changes to how these things are handled with some methods getting deprecated and even removed. I am not an expert on this area, but it involves HAL, DBUS, PLUGDEG, UDEV, and possibly other systems, some of which may not be used anymore.
I must agree whole heartedly with this analysis. There are hundreds of "moving parts" many of which are evolving quickly and leaving precious little documentation in that wake.

Quote:
Originally Posted by Noway2 View Post
The bottom line is that I don't have a definitive answer for you. I would look into what "system" assigns the default permissions for plug-able devices on Mint, or failing that Ubuntu as Mint is a derivative of it. If that isn't leading you anywhere, my next suggestion would to to try some of the IRC channels and see if you can get put in contact with the developers or package maintenance team.
One reason I'm posting to LQ is the attempt to locate someone or some group of folks who can shed light on this topic. Using 'find' I've been unable to locate anything that appears to make the changes that I'm seeing or doing anything that even remotely seems to be related.

Still seeking answers,
~~~ 0;-Dan
 
Old 06-25-2012, 11:55 AM   #9
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,324
Blog Entries: 3

Original Poster
Rep: Reputation: 86
IMPORTANT UPDATE
It seems that the 'libusb' errors during sudo commands might not be tied to the "plugdev" ownership issue.


I cold booted my laptop and completed a desktop login.
Without doing anything else, I opened a console with CTRL-ALT-F1 and completed a login as root. (I didn't want to use 'sudo' at all.)
On inspection, /dev/bus/usb/001/003 was group owned by "plugdev".
Since I was already root, I changed the ownership to root:root.

Returning to the desktop I opened an Xterm.
On inspection, all was root:root for the /dev/bus/usb/001 devices.
I tried a sudo command and still got the same error messages from 'libusb'.


FOLLOW-UP

Back at the console, I used 'su' to become a non-root user.
Next, as that user, I tried a 'sudo' command.
There were zero, none, nichts, nada, libusb error messages.

Back at the desktop, the libusb errors continued whenever sudo asked for a password.

Now I'm completely confused.
Can someone, ANYONE, shed some light on this?
~~~ 0;-/ Dan

Last edited by SaintDanBert; 06-25-2012 at 12:01 PM.
 
Old 06-26-2012, 02:33 AM   #10
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,531
Blog Entries: 27

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
The error messages are curious. Given "ls: cannot access /dev/usb: No such file or directory", why should sudo ls -lh /dev/usb generate a message about /dev/bus/usb/001/003 ?

What is the output from type sudo and sudo ls --version before running sudo ls -lh /dev/usb ?

Narrowing the differences between the test cases ...
  1. If you did not use the --login option of su (also -l and plain -) then please repeat the test in the last post using it.
  2. Please repeat the test using another virtual terminal (Ctrl+Alt+F2 from the X session) and logging in directly as the user you sued to.
 
Old 06-26-2012, 10:04 AM   #11
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,324
Blog Entries: 3

Original Poster
Rep: Reputation: 86
Quote:
Originally Posted by catkin View Post
The error messages are curious. Given "ls: cannot access /dev/usb: No such file or directory", why should sudo ls -lh /dev/usb generate a message about /dev/bus/usb/001/003 ?
I used 'sudo ls' as an example. It would not matter which {command} I supplied to 'sudo'.
In the example, I did not present a password to 'sudo' because I simply wanted to show the error messages.
Thus the {command} was never attempted.

Quote:
Originally Posted by catkin View Post
What is the output from type sudo and sudo ls --version before running sudo ls -lh /dev/usb ?
Given the above explanation, is that necessary any more?
Quote:
Originally Posted by catkin View Post
Narrowing the differences between the test cases ...
  1. If you did not use the --login option of su (also -l and plain -) then please repeat the test in the last post using it.
  2. Please repeat the test using another virtual terminal (Ctrl+Alt+F2 from the X session) and logging in directly as the user you sued to.
In a console, I did not get error reports from 'libusb'.

Here is what happened in an Xterm using a different {command} to 'sudo'.
Code:
#=== note that 'plugdev' is not a current issue
prompt$ ls -lh /dev/bus/usb/001/*

crw-rw-r-- 1 root root 189, 0 2012-06-25 11:46 /dev/bus/usb/001/001
crw-rw-r-- 1 root root 189, 1 2012-06-25 11:46 /dev/bus/usb/001/002
crw-rw-r-- 1 root root 189, 2 2012-06-25 11:46 /dev/bus/usb/001/003
crw-rw-r-- 1 root root 189, 3 2012-06-25 11:46 /dev/bus/usb/001/004
crw-rw-r-- 1 root root 189, 4 2012-06-25 11:46 /dev/bus/usb/001/005

#=== show that root access required for something
prompt $ tail /var/log/syslog
tail: cannot open `/var/log/syslog' for reading: Permission denied

#=== try same something with 'sudo'
prompt$ sudo tail /var/log/syslog
[sudo] password for user: 
libusb couldn't open USB device /dev/bus/usb/001/003: Permission denied.
libusb requires write access to USB device nodes.

... messages ...
Jun 26 09:47:31 kaywine acpid: client 1574[0:0] has disconnected
Jun 26 09:47:31 kaywine acpid: client connected from 1574[0:0]
Jun 26 09:47:31 kaywine acpid: 1 client rule loaded
Jun 26 09:47:31 kaywine kernel: [79109.959715] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Jun 26 09:48:05 kaywine wpa_supplicant[1141]: WPA: Group rekeying completed with c0:3f:0e:86:c7:f8 [GTK=CCMP]
(blush) It looks like I have other errors that I need to track down.

NOTICE that I still got the error reports from 'libusb' about /dev/bus/usb/001/003 in spite of the fact that it is user and group read-write. Perhaps I need to re-install 'libusb'...

I find the following files on my workstation:
Code:
prompt$ locate libusb

/lib/libusb-0.1.so.4
/lib/libusb-0.1.so.4.4.4
/lib/x86_64-linux-gnu/libusb-1.0.so.0
/lib/x86_64-linux-gnu/libusb-1.0.so.0.0.0
/lib32/libusb-0.1.so
/lib32/libusb-0.1.so.4
/lib32/libusb-0.1.so.4.4.4
/lib32/libusb-1.0.so
/lib32/libusb-1.0.so.0
/lib32/libusb-1.0.so.0.0.0
/lib32/libusb.so
/usr/lib/libusb-0.1.so.4

#=== and
prompt$ file /lib/libusb-0.1.so.4
/lib/libusb-0.1.so.4: symbolic link to `libusb-0.1.so.4.4.4'

prompt$ file /lib/libusb-0.1.so.4.4.4 
/lib/libusb-0.1.so.4.4.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

#=== and lastly
prompt$ ldd $(which sudo)

	linux-vdso.so.1 =>  (0x00007fff9d7d9000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ffe5a669000)
	libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007ffe5a45b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffe5a0b9000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffe59eb5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ffe5a898000)
NOTICE that 'sudo' does not reference 'libusb' so why do I get errors from there when I run 'sudo' anything?
... wait! 'sudo' launches a shell to run {command} so is this a shell problem?
My workstation is running:
Code:
prompt$ uname -a

Linux kaywine 3.0.0-19-generic #33-Ubuntu SMP Thu Apr 19 19:05:14 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Last edited by SaintDanBert; 06-26-2012 at 10:07 AM.
 
Old 06-27-2012, 07:35 AM   #12
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,531
Blog Entries: 27

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
type sudo could still be helpful because the unexplained behaviour is closely associated with sudo.

If the output is something sane like /usr/bin/sudo then it might be helpful to run strace sudo {command} but the strace output may be disabled when privilege is changed ...

The other anomaly is that the behaviour differs between running in a pseudo-terminal and in a terminal emulator. Perhaps the login/shell initialisation files behave differently depending on the terminal type, maybe following a test of the TERM variable. Assuming you are using bash it might be helpful to run (bash --login -xv) >{some file} 2>&1 (use Ctrl+C to terminate it) in both terminal types and diff the outputs.
 
Old 06-28-2012, 04:50 PM   #13
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,324
Blog Entries: 3

Original Poster
Rep: Reputation: 86
First, I get the following:
Code:
prompt$ type sudo
sudo is hashed (/usr/bin/sudo)

prompt$ type $(which sudo)
/usr/bin/sudo is /usr/bin/sudo

prompt$ file  $(which sudo)
/usr/bin/sudo: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
I may have posted this already:
Code:
prompt$ ldd $(which sudo)
	linux-vdso.so.1 =>  (0x00007fffa19a6000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fce125a0000)
	libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fce12392000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fce11ff0000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fce11dec000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fce127cf000)
I used your 'bash' command in three environments:
  • desktop,
  • console,
  • root console.
The desktop and console differ only in the $PATH value:
Code:
prompt$ cat desktop_console.diff 

63c63
< + PATH=/home/saint/bin:/home/saint/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
---
> + PATH=/home/saint/bin:/home/saint/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
As you might imagine, the root console vs. either plain user was radically different.
I can post those, but that hardly seems to apply to my symptoms.

I'm dashed to discover when and how 'libusb' gets involved to throw any error, much less a permission error..

Stumped,
~~~ 0;-Dan
 
Old 06-29-2012, 12:41 AM   #14
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,531
Blog Entries: 27

Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Quote:
Originally Posted by SaintDanBert View Post
I'm dashed to discover when and how 'libusb' gets involved to throw any error, much less a permission error.
Me too. At this point it makes no sense.

What happens if you set the same PATH as seen in the terminal emulator when testing in the pseudo-terminal and test again?

What does the output from strace sudo {command} look like? How does it differ between terminal types?

Long shot but has worked before when behaviour was inexplicable: you could try fsck on the file system.

Do you have or can you create a similar OS installation and check the MD5 sums of /usr/bin/sudo and the libraries it uses?
 
Old 06-29-2012, 09:58 AM   #15
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,324
Blog Entries: 3

Original Poster
Rep: Reputation: 86
Quote:
Originally Posted by catkin View Post
Me too. At this point it makes no sense.

What happens if you set the same PATH as seen in the terminal emulator when testing in the pseudo-terminal and test again?
I'll need more time to play with this one...

Quote:
Originally Posted by catkin View Post
What does the output from strace sudo {command} look like? How does it differ between terminal types?
Here are the results for 'strace' within an Xterm. I'll need more time to play here, too.
Code:
prompt$ tail /var/log/syslog
tail: cannot open `/var/log/syslog' for reading: Permission denied

prompt$ strace sudo tail /var/log/syslog

execve("/usr/bin/sudo", ["sudo", "tail", "/var/log/syslog"], [/* 41 vars */]) = 0
brk(0)                                  = 0x2359000
fcntl(0, F_GETFD)                       = 0
fcntl(1, F_GETFD)                       = 0
fcntl(2, F_GETFD)                       = 0
access("/etc/suid-debug", F_OK)         = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70263f0000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=170810, ...}) = 0
mmap(NULL, 170810, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f70263c6000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libutil.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=10640, ...}) = 0
mmap(NULL, 2105608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7025fcf000
mprotect(0x7f7025fd1000, 2093056, PROT_NONE) = 0
mmap(0x7f70261d0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f70261d0000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libpam.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`$\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=55848, ...}) = 0
mmap(NULL, 2150944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7025dc1000
mprotect(0x7f7025dcd000, 2097152, PROT_NONE) = 0
mmap(0x7f7025fcd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7f7025fcd000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1685816, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70263c5000
mmap(NULL, 3801960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7025a20000
mprotect(0x7f7025bb7000, 2093056, PROT_NONE) = 0
mmap(0x7f7025db6000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x196000) = 0x7f7025db6000
mmap(0x7f7025dbb000, 21352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7025dbb000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14768, ...}) = 0
mmap(NULL, 2109704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f702581c000
mprotect(0x7f702581e000, 2097152, PROT_NONE) = 0
mmap(0x7f7025a1e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f7025a1e000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70263c4000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70263c2000
arch_prctl(ARCH_SET_FS, 0x7f70263c2720) = 0
mprotect(0x7f7025a1e000, 4096, PROT_READ) = 0
mprotect(0x7f7025db6000, 16384, PROT_READ) = 0
mprotect(0x7f7025fcd000, 4096, PROT_READ) = 0
mprotect(0x7f70261d0000, 4096, PROT_READ) = 0
mprotect(0x626000, 4096, PROT_READ)     = 0
mprotect(0x7f70263f2000, 4096, PROT_READ) = 0
munmap(0x7f70263c6000, 170810)          = 0
brk(0)                                  = 0x2359000
brk(0x237a000)                          = 0x237a000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=7224800, ...}) = 0
mmap(NULL, 7224800, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7025138000
close(3)                                = 0
geteuid()                               = 1000
write(2, "sudo", 4sudo)                     = 4
write(2, ": ", 2: )                       = 2
write(2, "must be setuid root", 19must be setuid root)     = 19
write(2, "\n", 1
)                       = 1
exit_group(1)                           = ?
I don't see anything suspicious. I also do not see any reference to 'libusb'.
(blush) I also did not make sure that I'm still getting the error. Something I failed to be before this test.
Sorry, Arnold, but I'll be back...

Quote:
Originally Posted by catkin View Post
Long shot but has worked before when behaviour was inexplicable: you could try fsck on the file system.
I forget the trick to running 'fsck' on a laptop "system" drive's file systems. Do I need a live distro
or is there something else?

Quote:
Originally Posted by catkin View Post
Do you have or can you create a similar OS installation and check the MD5 sums of /usr/bin/sudo and the libraries it uses?
Isn't there some way to simply re-install the "sudo package" from the repositories?

Stumpled,
~~~ 8d;-/ Dan
 
  


Reply


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] Getting permission denied when running "sudo bash" Clariollo Red Hat 6 01-25-2012 02:18 PM
LXer: Tutorial: Fixing sudo Permission Denied Errors LXer Syndicated Linux News 0 07-08-2010 04:00 AM
Displayign what user is running sudo commands jakev383 Linux - Security 1 08-04-2009 03:01 PM
Lots of errors when running an app with sudo bruno321 Ubuntu 2 02-23-2007 04:21 AM
rewriting libusb errors lucky6969b Programming 0 05-22-2006 10:08 PM


All times are GMT -5. The time now is 06:26 PM.

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration