-   Slackware (
-   -   Slackware14.0 + /dev/null permission denied (

perseus12 10-23-2012 08:26 PM

Slackware14.0 + /dev/null permission denied
Hi all,

This is my 1st posting on LQ so I hope I have described the problem clearly.
I have installed 14.0 on a laptop; installation consists of everything in the disksets: a, ap, d, l, n, and x.
I have noticed the following problem:
if I run a command like:
su -c "ls -l &>/dev/null" reguser

I get the following error:
bash: /dev/null: Permission denied.

reguser is just a normal user login name and the example is intentionally simple. I have scripts that are executed as root and
run some commands as a normal user, redirecting their output to /dev/null. These scripts work on 13.37 but not on 14.0.

So if I do the following:
(1) On 14.0, as normal user: ls -l &>/dev/null - this works
(2) On 14.0, as root: ls -l &>/dev/null - this works
(3) On 14.0, as root: su -c "ls -l &>/dev/null" reguser - this fails
(4) On 13.37, as root: su -c "ls -l &>/dev/null" reguser - this works

On 14.0 and 13.7 /dev/null has the following permissions:
crw-rw---- 1 root audio 1, 3

Of course reguser belongs to group 'audio'.

I have noticed on the gentoo and archlinux forums the same problem
has cropped up for some users; no solutions are given, but a workaround is to change the perms for /dev/null to rw-rw-rw.

Any ideas as to what is going on?
Anything I can try to narrow down the problem?


allend 10-23-2012 08:50 PM

Welcome to LQ!

On my 32bit install,

bash-4.2$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Oct 13 23:51 /dev/null

The permissions are set by a rule in /lib/udev/rules.d/50-udev-default.rules

KERNEL=="null|zero|full|random|urandom", MODE="0666"
Have you installed anything that might override the default udev rule?
Perhaps check the contents of /etc/udev/rules.d/

GazL 10-24-2012 04:34 AM

su -c "ls -l &>/dev/null" reguser does not change the current directory, so if you are in root's home directory, or some other place that reguser cannot read and you 'su' to reguser and then try and 'ls' it won't have permission to read the directory entries. It is the 'ls' that is failing, not the writing to /dev/null.

su -l reguser -c "ls -l" will work (assuming it is reguser's files that you want to list) as it will change to reguser's home directory before attempting the 'ls'

I have no idea why it was working on 13.37. I can only assume that the current directories permissions were different when you did this on 13.37.

Oh, and welcome to LQ. :)

perseus12 10-24-2012 07:43 AM

Thanks for the welcome.

'su -l reguser -c "ls -l &>/dev/null"' gives error: /etc/profile: line 69: /dev/null permission denied.

line 69 is 'biff y 2>/dev/null', so again trying to redirect to /dev/null.

I agree with you I do not know why the SAME command works on 13.37.
It should also work on 14 since reguser belongs to group audio and /dev/null has
rw access for audio...

You gave me a hint so I looked at /dev and every entry is owned by (root, audio)!!
I looked at 13.37 and it is identical. Finally the light bulb went on in my head,
this is all wrong!!

My guess is that some package I have built and installed caused this. (To learn some things I have been building and installing packages from the slackware source repository.)

Anyway I am taking a look at ALL files in /lib/udev/rules.d to see if any file
could be causing this and which package it is from. So far no luck.

Will let you guys know...thanks for the help.

allend 10-24-2012 07:47 AM

The OP reported

On 14.0 and 13.7 /dev/null has the following permissions:
crw-rw---- 1 root audio 1, 3
Even if the 'ls' is failing, there is still an inconsistency on the permissions on /dev/null

I am posting from a Slackware 13.37 32 bit install, where the permissions on /dev/null show as

bash-4.1$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Oct 24 23:18 /dev/null

I suspect the OP is using an audio package that is installing custom udev rules.

[edit] The OP posted before I had finished my reply! [/edit]

GazL 10-24-2012 07:59 AM

Yes, I agree there does appear to be two separate errors at play here.

perseus12 10-25-2012 12:36 PM

Solved: Slackware14.0 + /dev/null permission denied
Yep you guys are right.

I have found the reason why everything in /dev gets reassigned to group 'audio':
it is a modified version of libmtp.

I have modified the rules for 'libmtp' otherwise I can't use gnomad as reg user.
So I have added GROUP="audio", MODE="0660" throughout... here's an excerpt:
# Creative ZEN Vision
ATTR{idVendor}=="041e", ATTR{idProduct}=="411f", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1", GROUP="audio", MODE="0660"
# Creative Portable Media Center
ATTR{idVendor}=="041e", ATTR{idProduct}=="4123", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1", GROUP="audio", MODE="0660"
# Creative ZEN Xtra (MTP mode)
ATTR{idVendor}=="041e", ATTR{idProduct}=="4128", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1", GROUP="audio", MODE="0660"

I have been using this for a few years (at least since 12.0) and it must have been changing the perms in /dev since then, but the problem with /dev/null is
only occuring with 14.0.

So in summary:
(1) corruption of perms in /dev has been solved; scripts now work ok.
(2) don't know why udev reassigns group to 'audio' to everything in /dev when
it encounters ', GROUP="audio", MODE="0660"' in libmtp rules; I'll check if
format of udev rules has changed
(3) why does Slack 14 (tty+su) fail on redirection and Slack<14 does not?

BTW: how can I allow things like gnomad to use devices as a reg user?

Thanks a lot.

All times are GMT -5. The time now is 11:44 PM.