Re: ownership of devices

[Pieter Meiring <nospam [at] sheffield.ac.uk>]

> sheflug - http://home.freeuk.net/shef.lug
>
> >>>>> Pieter == Pieter Meiring <p.d.meiring [at] sheffield.ac.uk> writes:
>
> >> My /dev directory seems to contain a lot of devices owned by my
> >> non-root username. This can't be right can it? What could be
> >> causing this to happen?
>
> Pieter> This is a buglet.
>
> Not necessarily. (If you _know_ better, please provide citation where
> I can upgrade my background knowledge.) My suspicion is that it is a
> truly wizardly hack.
>
You are right, I do not _know_ better!. However, my reasoning was as follows:

A came across a situation where, after installing Mandrake, some users logging
on suddenly were unable to access /dev/audio and /dev/mixer and a few other
miscellaneous /dev/files. Upon looking at these, I discovered that while most
of the /dev/files were owned by root, several were owned by other two other
users - these being user names that personaly use.
When setting up Mandrake with linuxconf and other utilities, I almost always
log in as a user and then use su or sudo to run root requiring utilities and I
do remember logging in as both these users when running root-requiring
configuration programs such as linuxconfig, sndconfig, etc.
Although other users logged in in both text and X modes, none of the devices
were altered to reflect new ownership. Neither could they access some of these
devices.
However, when running su or sudo and preforming file creation, the file
ownerships are usually root.root so some sort of wizardry is at work. It is a
fact that when using su (but not su -), the environmental variable USER is
_not_ changed to root whereas the variable USERNAME is changed to root. If the
configuration program used the USER variable to determine what to set
ownership of created files then this could be an explanation.
This was the basis for my supposition in my post.

> The old way to handle the problem of devices was to have them owned by
> root (or some suitable group), provide suid root (sgid suitable group)
> binaries, and do file locking to avoid conflicts on multiuser systems.
> sgid suitable group is a sys admin nightmare, and in some cases can
> still allow DOS[1] attacks. suid root is like ringing the dinner bell
> and calling crackers, Come and get it!
>
As you say, SUID and SGID is dangerous. I prefer to use user groups and set
permissions accordingly. If a user is allowed floppy access, he is added to
the floppy group - there is no need for a SGID program to access that device.
If your cracker cracks the password/group security your system has been
thoroughly compromised anyway!

> An alternative path is to provide _one_ carefully checked out suid
> root binary whose _only_ function is to change the ownership of
> certain devices to the id of users currently logged in on the console.
> Note that this removes the need for file locking. I'm not sure if
> this could be done safely via kmod/kerneld, but I don't really see why
> not; in that case you would never know.... (Hmmm. If they're not
> doing that, maybe I should patent the idea ;-)
>
Where two users on the system need to use the same device only sequentially
access would be possible and one would have to change ownership on the fly
which would be equivalent to locking and unlocking....

> Note the devices in question: major 14/35 (audio), major 29 (frame
> buffer = graphical console), major 2 (floppy), major 15 (joystick, I
> bet), major 4 (tty). I dunno about major 7 (virtual console?), and
> major 22 (hdc) is probably the CD-ROM, so a removable device where
> non-privy users need to mount.
>
Almost all these devices are configured after basic installation...
Audio with sndconfig
Video with X configuration
CDROM is detected and a hard or soft link applied

Other than this conjecture I have no proof - I may, when I have time, have a
look at the source of the installation process...

Best Wishes
Pieter

Start your own FREE mailing list at

&copy; 2000 Microsoft Corporation. All Rights Reserved