[lkml]   [2001]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: devfs unable to handle permission: 2.4.17-pre[4,5] / ALSA-0.9.0beta[9,10]
On Thu, 6 Dec 2001 23:09:14 -0700
Richard Gooch <> wrote:

> Rene Rebe writes:
> > At least since 2.4.17-pre4 and -pre5 devfs is not handling
> > permissions in the right way with ALSA:
> Please define what is the "right way".

Sorry I toght the commands wabout would be enought:

As root they are listable and read and writeable (for examples via ls -l,
cat /dev/dsp > ~/my-speach.snd or cat ~/my-speach.snd > /dev/dsp), ussing
mpg123 ...

> > rene@jackson:/dev > l dsp sound/dsp
> > ls: sound/dsp: Permission denied
> > lr-xr-xr-x 1 root root 9 Dec 7 00:14 dsp -> sound/dsp
> > rene@jackson:/dev > cd sound/
> > bash: cd: sound/: Permission denied
> > rene@jackson:/dev >
> >
> > rene@jackson:/dev > l snd
> > ls: snd/..: Permission denied
> > ls: snd/.: Permission denied
> > ls: snd/controlC0: Permission denied
> > ls: snd/controlC1: Permission denied
> > ls: snd/timer: Permission denied
> > ls: snd/midiC0D0: Permission denied
> > ls: snd/pcmC0D2p: Permission denied
> > ls: snd/pcmC0D1c: Permission denied
> > ls: snd/pcmC0D0p: Permission denied
> > ls: snd/pcmC0D0c: Permission denied
> > ls: snd/midiC1D0: Permission denied
> > ls: snd/pcmC1D0p: Permission denied
> > ls: snd/pcmC1D0c: Permission denied
> > total 0
> >
> > They all have 666 (or 777 for dirs)!
> Are you saying this is good or bad?

This is good. The permissions of the files are correct (everyone can use
sound), but I can (as you see in the command's output) neither access nor
read/write them as normal user - but all this works as root.

> > It is possible to this as root.
> It's possible to do what? List the inodes? Open then? What?

Yes. All this is possible as root but not using anothe UID.

> > Also loading the modules gives me:
> > Dec 7 00:31:58 jackson kernel: devfs: devfs_register(unknown): could not append to parent, err: -17
> Two possibilities:
> - the module is trying to register "unknown" twice. The old devfs core
> was forgiving about this (although it was always a driver bug to
> attempt to create a duplicate). The new core won't let you do that.
> Error 17 is EEXIST. Please fix the driver
> - something in user-space created the "unknown" inode before the
> driver could create it. This is a configuration bug. It seems
> Mandrake has boot scripts which indiscriminately "restore" inodes in
> /dev. This is a bug, because they also restore inodes created by the

I do not restore devices-nodes un reboot.

> drivers, whereas they should only be restoring admin-created inodes.
> Grab devfsd-v1.3.20 which has the RESTORE directive which does this
> properly, and blow away the part of the Mandrake boot scripts which
> are causing the problem

I use the devfsd.conf to configure the permission when a device registers.

> FYI: what happens now with duplicates is that the old entry remains,
> and the new one is discarded. If you really are creating the same
> entry, there should be no harm, just that annoying message.

The device-nodes seems to be all there they work as root, but not as normal
user. But it seems to be a ALSA issue, because only the ALSA nodes have this
strange behaviour ... ?

> Regards,
> Richard....
> Permanent:
> Current:

Have to leave now - can respond again in 8 hours ...

k33p h4ck1n6

René Rebe (Registered Linux user: #248718 <>)



Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.130 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site