[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ownership of devices
>>>>> Martin == Martin P Holland <m.holland [at] noether.freeserve.co.uk> writes:
Martin> I don't have any such security concerns :-)
Good for you.
Martin> Anyhow it seems that if martin logs on one console then he
Martin> grabs all the devices I mentioned before. Now if jacqui
Martin> logs on on another console then she will get the devices
Martin> corresponding to that console but she doesn't reclaim the
Martin> sound,floppy,cd etc. So sound at least is broken for
Martin> jacqui unless martin logs out before jacqui logs in.
Well, this shouldn't happen at login; that is broken design. It
should be done when a request is made to the kernel to use a device
service. (I don't know that that is possible using kmod, although
kerneld can do anything; still in theory.) There should also be a
service whereby a client can grab a device, and reserve it for own
use, presumably with a timeout.
Martin> After all my only other user is jacqui and she knows the
Martin> root password anyhow.
In that situation you could just chmod a+rw all the audio, fb, and
removable block devices. I would prefer figuring out how to make it
work as intended, but (even though I suspect in principle you feel
that way too) it sounds like that's not a priority for you right now.
Martin> Strangely although martin owns the floppy device this
Martin> doesn't seem to stop jacqui reading and writing to it. So
Martin> that isn't broken. It just seems to be the sound that
Martin> doesn't play well, if you excuse the pun.
Probably the permissions on the floppy device allow everybody to read
and write (see above). Mounting will probably depend on the
permissions of the /dev directory as well as the floppy mount point.
>> The real solution for this is a network-ready audio daemon like
>> NAS.
Martin> Does that work at the X-level?
Not exactly. NAS is a protocol like X, optimized for sound (as of
1992 or so ;-), that runs in parallel to X. If you are running X,
then NAS clients use the DISPLAY environment variable to find an NAS
server on the same host. Other than that there is no direct
relationship. You can set AUDIOSERVER in the environment or use a
command line argument to override that default.
Martin> Well I may give it a go when I play at home networking
Martin> (when funds permit).
Even in Japan, funding a HAN only requires giving up beer (or orange
juice) for a week. ;-) Go for it! (Assuming you've got two desktop
boxes; PCMCIA cards are still expensive :-( ).
For future reference:
(1) Debian unstable has nearly 4000 packages (including the contrib,
non-free, non-US and JP distributions). This is in part due to
splitting packages rather finely (Perl, Python, and ruby modules alone
account for over 100 packages, and many packages' documentation are
split from the package itself). The default tool for package
management, dselect, is basically overwhelmed by this. It is very
difficult to maintain a lean system any more.
(2) With some work, Debian systems can be a lot leaner than RH and TL
systems, because the packages are more finely split and you can leave
out what you don't need.
(3) Strict rules on packaging with good documentation and tools to
check and enforce them mean that contributed packages generally work
well (ie, install and configure appropriately - the program itself may
crash ;-), even though most package maintainers only maintain one
package and do not do any core Debian work at all.
(4) Debian uses scripts (sh, Perl, or Python usually) to configure
packages. If you can read scripts, you can often fix one that is
broken in your configuration.
(5) Debian has by far the best documentation; I often find I have real
manpages that none of the Slackware, Red Hat, or Turbolinux users I
know have access to. Many of the rest have pointers to Info or HTML
docs installed on the system, and all packages at least get a default
man page that explains common resources for dealing with undocumented
packages. Debian also packages things like the more commonly
referenced RFCs and the IANA's assigned number list and the MIME
charset registry.
(6) Debian has style rules that may be offputting; the idea is to
enforce some basic rules about menus and so on across all Debian
systems, whether they use KDE or don't have X installed. This means
that fvwm and windowmaker (the two window managers I use most) look
very different in their normal Debian configuration from their
defaults. Be prepared for that....
(7) Interestingly enough, despite the fact that Debian unstable
follows the release of XFree86 and glibc closely, I have never been
hosed by an upgrade (with the single exception that glibc upgrades
generally break my XEmacs - but that's because I'm a beta tester and
XEmacs is always bleeding edge; it have _never_ broken the Debian-
distributed XEmacs for me, and I've checked. And besides, the glibc
developers go out of their way to break XEmacs ;-).
(8) I have been screwed by dependency bugs, though; for a while I was
unable to upgrade Perl because of a twisty maze of dependencies.
However, that was solved by putting Perl on hold for a couple of
weeks.
(9) Debian unstable will be at least as up to date (on average) as the
RH development tree, but substantialy more stable. (Partially because
RH does more tweaking of the upstream source code; Debian often
watches to see if RH's patches look good, then adopts them.)
All in all, I would say that Debian compares to RH et al the way Linux
does to Windows. The former are generally more robust, and a
knowledgable user will find it easier to tweak the system into
working. The latter are more user-friendly, if the user is willing to
buy the hardware that works with them ;-)
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
What are those two straight lines for? Free software rules.
Start your own FREE mailing list at
© 2000 Microsoft Corporation. All Rights Reserved