Hi,
I have been playing with an USB camera. I've run into the following
problem:
The (default?) permissions for /proc/bus/usb/001/011 (and others) are
0644. This makes the ioctl (see attached trace to fail). So I have to:
either chmod the usb device file each time I unplug and replug the camera
OR make the pencam program SUID root, which is neither comfortable.
Is there a way to affect the default permissions for the USB devices?
regards
Kees
In article <[email protected]>,
kees <[email protected]> writes:
k> This message is in MIME format. The first part should be readable text,
k> while the remaining parts are likely unreadable without MIME-aware tools.
k> Send mail to [email protected] for more info.
k>
k> ---1463801846-915869288-1007668919=:13843
k> Content-Type: TEXT/PLAIN; charset=US-ASCII
k>
k> Hi,
k>
k> I have been playing with an USB camera. I've run into the following
k> problem:
k> The (default?) permissions for /proc/bus/usb/001/011 (and others) are
k> 0644. This makes the ioctl (see attached trace to fail). So I have to:
k> either chmod the usb device file each time I unplug and replug the camera
k> OR make the pencam program SUID root, which is neither comfortable.
k> Is there a way to affect the default permissions for the USB devices?
Use hotplug to run a script to change the permissions when the device
is connected. Mail me off list for an example.
On Thu, 06 Dec 2001 20:14:47 GMT
Jonathan Hudson <[email protected]> wrote:
> In article <[email protected]>,
> kees <[email protected]> writes:
> k> This message is in MIME format. The first part should be readable text,
> k> while the remaining parts are likely unreadable without MIME-aware tools.
> k> Send mail to [email protected] for more info.
> k>
> k> ---1463801846-915869288-1007668919=:13843
> k> Content-Type: TEXT/PLAIN; charset=US-ASCII
> k>
> k> Hi,
> k>
> k> I have been playing with an USB camera. I've run into the following
> k> problem:
> k> The (default?) permissions for /proc/bus/usb/001/011 (and others) are
> k> 0644. This makes the ioctl (see attached trace to fail). So I have to:
> k> either chmod the usb device file each time I unplug and replug the camera
> k> OR make the pencam program SUID root, which is neither comfortable.
> k> Is there a way to affect the default permissions for the USB devices?
>
> Use hotplug to run a script to change the permissions when the device
> is connected. Mail me off list for an example.
This is what I do - but IT SUCKS!! Can't the USB stuff simply use devfs so
I can control the permissions of this USB nodes in a very nice / cleaner
way I do with all my other stuff??? (In contrast to use some find -name
| xargs chmod ... or simillar hacks ...)
Please
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
Homepage: http://www.tfh-berlin.de/~s712059/index.html
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.
On Thu, Dec 06, 2001 at 10:30:50PM +0100, Rene Rebe wrote:
>
> This is what I do - but IT SUCKS!! Can't the USB stuff simply use devfs so
> I can control the permissions of this USB nodes in a very nice / cleaner
> way I do with all my other stuff??? (In contrast to use some find -name
> | xargs chmod ... or simillar hacks ...)
How is using devfs (and devfsd) any different in "hack level" from using
/sbin/hotplug?
usbdevfs does not require devfs, which enables the majority of Linux
users to actually use it.
thanks,
greg k-h
On Thu, 6 Dec 2001, Greg KH wrote:
> On Thu, Dec 06, 2001 at 10:30:50PM +0100, Rene Rebe wrote:
> >
> > This is what I do - but IT SUCKS!! Can't the USB stuff simply use devfs so
> > I can control the permissions of this USB nodes in a very nice / cleaner
> > way I do with all my other stuff??? (In contrast to use some find -name
Because anybody who uses devfs might as well make everything in /dev 666
and do the same with /etc/shadow while we are at it?
> > | xargs chmod ... or simillar hacks ...)
>
> How is using devfs (and devfsd) any different in "hack level" from using
> /sbin/hotplug?
>
> usbdevfs does not require devfs, which enables the majority of Linux
> users to actually use it.
s/majority of/& sane/
On Thu, 6 Dec 2001 15:27:22 -0800
Greg KH <[email protected]> wrote:
> On Thu, Dec 06, 2001 at 10:30:50PM +0100, Rene Rebe wrote:
> >
> > This is what I do - but IT SUCKS!! Can't the USB stuff simply use devfs so
> > I can control the permissions of this USB nodes in a very nice / cleaner
> > way I do with all my other stuff??? (In contrast to use some find -name
> > | xargs chmod ... or simillar hacks ...)
>
> How is using devfs (and devfsd) any different in "hack level" from using
> /sbin/hotplug?
Maybe nothing in Linux should be at an hack-level I we would like to
get more desktop users ;-) (NO I'm not such a dummie user!)
Devfsd:
REGISTER snd/* PERMISSIONS root.root 666
REGISTER sound/* PERMISSIONS root.root 666
For usbfs I have to do script-hacking in /sbin/hotplug (I do not know
how I did it since it is on my brothers box somewhere at the other
end of Germany ... - but is was some if [$1 = "usb"]; then; chmod
or maybe even some find /proc -name "xyz..." ...). Especially because
I only got one parameter ($1 == usb?) the rest was empty. So even
providing filesnames what got hot-plugged would be nice.
> usbdevfs does not require devfs, which enables the majority of Linux
> users to actually use it.
Wouldn't it be nicer to use devfs and add this procfs hack for the
"major dists"? - They could even mount devfs to /devfs and so use
all the old-way in /dev and only use devfs for the usb stuff.
I do not know why they adapt so slowly to such a cool technology
anyway ...
> thanks,
>
> greg k-h
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
Homepage: http://www.tfh-berlin.de/~s712059/index.html
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.
Hi.
On Thu, 6 Dec 2001 18:37:44 -0500 (EST)
Alexander Viro <[email protected]> wrote:
> On Thu, 6 Dec 2001, Greg KH wrote:
>
> > On Thu, Dec 06, 2001 at 10:30:50PM +0100, Rene Rebe wrote:
> > >
> > > This is what I do - but IT SUCKS!! Can't the USB stuff simply use devfs so
> > > I can control the permissions of this USB nodes in a very nice / cleaner
> > > way I do with all my other stuff??? (In contrast to use some find -name
>
> Because anybody who uses devfs might as well make everything in /dev 666
> and do the same with /etc/shadow while we are at it?
Huh?? Not I!
LOOKUP loop/* MODLOAD
LOOKUP input/js* MODLOAD
LOOKUP ppp MODLOAD
LOOKUP usb/lp0 MODLOAD
REGISTER scsi/* PERMISSIONS root.daemon 660
The last is needed for CD buring - and this is a workstation anyway.
rene@jackson:/etc > l /etc/shadow
-rw-r----- 1 root shadow 258 Nov 11 23:02 /etc/shadow
I really like devfs (most) for the sane names, and all the other features
found in Richards texts.
Where is THE problem with permissions??
Especially for the permissions point usbfs is bad. Because you never know
what device belongs to what. For examples replug a device or take the Canon
IXUS, wich switch off every 30 seconds without data-transfer. Each time you
get a new criptic usbfs file you have to chmod 666 it blindly ... ???
Btw. Linux might be more insecure due to the many bugs I had to stumble over
in the last month ... (-> so I decided to donate some time reporting each
bug I find [and for my newest RAID one I take a look myself ...])
> > > | xargs chmod ... or simillar hacks ...)
> >
> > How is using devfs (and devfsd) any different in "hack level" from using
> > /sbin/hotplug?
> >
> > usbdevfs does not require devfs, which enables the majority of Linux
> > users to actually use it.
>
> s/majority of/& sane/
Writing bash scripts is easier than adding two lines to devfsd.conf?? Btw.
sane users do not use such a mahor/messy distro ...
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
Homepage: http://www.tfh-berlin.de/~s712059/index.html
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.
On Fri, Dec 07, 2001 at 12:45:21AM +0100, Rene Rebe wrote:
>
> For usbfs I have to do script-hacking in /sbin/hotplug (I do not know
> how I did it since it is on my brothers box somewhere at the other
> end of Germany ... - but is was some if [$1 = "usb"]; then; chmod
> or maybe even some find /proc -name "xyz..." ...). Especially because
> I only got one parameter ($1 == usb?) the rest was empty. So even
> providing filesnames what got hot-plugged would be nice.
It's there in the DEVICE environment variable. See
http://linux-hotplug.sourceforge.net/?selected=usb for more
documentation.
So a simple /sbin/hotplug script of:
#!/bin/sh
if [ "$1" == "usb" ]; then
chmod 666 $DEVICE
fi
would work just fine for your needs.
> Wouldn't it be nicer to use devfs and add this procfs hack for the
> "major dists"? - They could even mount devfs to /devfs and so use
> all the old-way in /dev and only use devfs for the usb stuff.
It's not a procfs hack, it is a stand alone filesystem. The fact that
you happen to mount it within the /proc filesystem is your option.
The USB developers did not want to force people to use devfs to use USB
devices, and based on the fact that not a single distro is using devfs
(the one that did, now recommends that you disable it) backs up this
choice.
> I do not know why they adapt so slowly to such a cool technology
> anyway ...
See the numerous lkml posts about why this is so.
thanks,
greg k-h
On Fri, 7 Dec 2001, Rene Rebe wrote:
> > > usbdevfs does not require devfs, which enables the majority of Linux
> > > users to actually use it.
> >
> > s/majority of/& sane/
>
> Writing bash scripts is easier than adding two lines to devfsd.conf?? Btw.
> sane users do not use such a mahor/messy distro ...
Sane users don't run stuff with known unfixable security holes. The only
variant that has any promise to get that crap fixed got no testing to
speak about.
Ask Richard if you don't believe me - or grep the l-k archives. Again,
all variants of devfs up to and including 2.4.16 are unfixable according
to devfs author.
BTW, which distro are you talking about?
On Thu, 6 Dec 2001 16:00:55 -0800
Greg KH <[email protected]> wrote:
Ok I did not searched this far. But this way you also change the nodes for
USB hard-discs, net-interfaces, ... to 666 - the same insecure as my find
solotion ...
> So a simple /sbin/hotplug script of:
> #!/bin/sh
> if [ "$1" == "usb" ]; then
> chmod 666 $DEVICE
> fi
>
> would work just fine for your needs.
> It's not a procfs hack, it is a stand alone filesystem. The fact that
> you happen to mount it within the /proc filesystem is your option.
Yes my mistake - sorry.
> The USB developers did not want to force people to use devfs to use USB
> devices, and based on the fact that not a single distro is using devfs
> (the one that did, now recommends that you disable it) backs up this
> choice.
OK. Might be well for backward-compatibility - but the devfs solution
would be a very nice option.
> > I do not know why they adapt so slowly to such a cool technology
> > anyway ...
>
> See the numerous lkml posts about why this is so.
We at ROCK linux (www.rocklinux) use it for years - and never had a
problem (maybe some have - because they use the http://www.ibm.org/linu-docs-somewhere
approach of taring them on shutdown and untar it on bootup. Using devfsd.conf
is hust fine! (I'll try to search the archive for devfs posts ...)
> thanks,
>
> greg k-h
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
Homepage: http://www.tfh-berlin.de/~s712059/index.html
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.
On Thu, 6 Dec 2001 19:09:57 -0500 (EST)
Alexander Viro <[email protected]> wrote:
> On Fri, 7 Dec 2001, Rene Rebe wrote:
>
> > > > usbdevfs does not require devfs, which enables the majority of Linux
> > > > users to actually use it.
> > >
> > > s/majority of/& sane/
> >
> > Writing bash scripts is easier than adding two lines to devfsd.conf?? Btw.
> > sane users do not use such a mahor/messy distro ...
>
> Sane users don't run stuff with known unfixable security holes. The only
> variant that has any promise to get that crap fixed got no testing to
> speak about.
Hm. OK. Due to lag of time I was too long not on the mailing-list. :-(
I this is true it is a very strong point aganst devfs :-[[
> Ask Richard if you don't believe me - or grep the l-k archives. Again,
> all variants of devfs up to and including 2.4.16 are unfixable according
> to devfs author.
Hm.
> BTW, which distro are you talking about?
ROCK Linux (http://www.rocklinux.org)
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
Homepage: http://www.tfh-berlin.de/~s712059/index.html
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.
On Fri, Dec 07, 2001 at 01:11:34AM +0100, Rene Rebe wrote:
>
> Ok I did not searched this far. But this way you also change the nodes for
> USB hard-discs, net-interfaces, ... to 666 - the same insecure as my find
> solotion ...
I was making a simple script, to match your simple defvsd line. Yes,
you can (and should) make this more complex. See the linux-hotplug
mailing list for a recent discussion by the gphoto developers about
this very problem.
> OK. Might be well for backward-compatibility - but the devfs solution
> would be a very nice option.
Will not happen.
thanks,
greg k-h
Alexander Viro writes:
>
>
> On Fri, 7 Dec 2001, Rene Rebe wrote:
>
> > > > usbdevfs does not require devfs, which enables the majority of Linux
> > > > users to actually use it.
> > >
> > > s/majority of/& sane/
> >
> > Writing bash scripts is easier than adding two lines to devfsd.conf?? Btw.
> > sane users do not use such a mahor/messy distro ...
>
> Sane users don't run stuff with known unfixable security holes. The
> only variant that has any promise to get that crap fixed got no
> testing to speak about.
I gave it as much testing as I could, but there comes a point where
you don't get any more test reports (because people are lazy) where
you have to throw it out for a pre-patch which *will* get testing.
I got tired of begging for people to test it.
Basic chicken and egg problem. It's the same reason Linus released
2.4.0-test* when it was really 2.3.99++.
> Ask Richard if you don't believe me - or grep the l-k archives.
> Again, all variants of devfs up to and including 2.4.16 are
> unfixable according to devfs author.
It's a matter of degree. I did fix it, by putting locking and
refcounting in. Is that a re-write or a fix? It's a grey area. I've
been calling it a re-write, but you could also argue that it's "fix".
My main claim is that the old core wasn't amenable to fixing with a
few tweaks here and there.
Anyway, this is all semantics and history. All that matters is that
the latest code is much better, and I'm working on getting the last
wrinkles out. We're still in a pre-patch, so no need to panic yet.
I've been diligent about fixing things (mostly battling with
incomplete bug reports).
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Thu, 6 Dec 2001 17:21:44 -0700
Richard Gooch <[email protected]> wrote:
> I gave it as much testing as I could, but there comes a point where
> you don't get any more test reports (because people are lazy) where
> you have to throw it out for a pre-patch which *will* get testing.
> I got tired of begging for people to test it.
OK. Here I'm send me all you would like to get tested!
> Basic chicken and egg problem. It's the same reason Linus released
> 2.4.0-test* when it was really 2.3.99++.
I use devfs for years on workstations. I never had major problems, only
that ALSA needs a few days to follow changes, and some string
cripling when modprobe is called (solved for months) ...
[...]
> Anyway, this is all semantics and history. All that matters is that
> the latest code is much better, and I'm working on getting the last
> wrinkles out. We're still in a pre-patch, so no need to panic yet.
> I've been diligent about fixing things (mostly battling with
> incomplete bug reports).
I try to get more details (than I had in the last IDE one) into my next
reports - sorry ;-)
> Regards,
>
> Richard....
> Permanent: [email protected]
> Current: [email protected]
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
Homepage: http://www.tfh-berlin.de/~s712059/index.html
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.