On Wed, 1 Apr 2009 21:24:16 -0400 Nick Guenther <[email protected]> wrote:
> On Wed, Apr 1, 2009 at 10:48 AM, J.C. Roberts > <[email protected]> wrote: > > On Wed, 1 Apr 2009 04:46:10 +0000 Jacob Meuser > > <[email protected]> wrote: > > > >> On Tue, Mar 31, 2009 at 07:13:33PM -0700, OpenBSD wrote: > >> > Hello > >> > > >> > Could somebody please tell me how to use a dvd-rw as user? > >> > I'am trying to install Slackware using qemu, and the dvd does not > >> > work properly, it works well as root. I've tried adding the user > >> > to operator group, users group, and declaring it at fstab without > >> > optimum results. > >> > >> by default root can read and write /dev/rcd0c. operator group can > >> only read. > >> > >> you need to be able to write to /dev/rcd0c to put a filesystem on > >> a cd/dvd. > >> > >> you can change the permissions on /dev/rcd0c or use sudo. > > > > Using sudo is a great way to handle this situation, but this depends > > on how much you trust the user, and whether or not you can properly > > configure /etc/sudoers with visudo. > > > > NOTE: Jake only said "change the permissions" but he did not say to > > change them permanently on disk. Of course, changing permissions > > permanently on disk is an option, but in many situations it is not > > the best option. > > > > If as root you fumble-finger the chown/chmod command on your > > devices, stuff a user into the wrong group, or don't fully > > understand all the esoteric issues involved in device permissions, > > you could easily be in a world of hurt. > > > > If you really want to go the route of changing permissions on a > > workstation, the best way to do it is using the existing features > > available /etc/fbtab to change permissions on devices automatically > > and temporarily at user login and logout. See man fbtab for details. > > > > This exact situation of an unprivileged local user needing access to > > devices is the reason why fbtab exists. > > > > Reading fbtab(5), it seems that it changes the device permissions > whenever any matching user logs in. So what happens if two users log > in (say, one on the first virtual term, one on the second)? Does the > second get control of all the devices and the first is just out of > luck? It depends on how you configure things. It's just a chmod, so you could set the permissions however you want (owner/group/everyone). At times you would *want* the other guy to be out of luck. The tty(4) used to login, is the trigger for fbtab to the change the permissions. If you look at your /etc/fbtab file, you'll find you're already using it. If you log into the first virtual terminal (i.e. the default), you're on /dev/ttyC0. If you log into the second virtual terminal, you're on /dev/ttyC1, and so on. Though they are called "Virtual Terminals" and you've got a number of them, they are, in essence, device files associated with "hardware terminal ports." Yes, the names, hardware versus virtual, do seem a bit contradictory until you read `man 4 tty` and think about it. The Virtual Terminals (normally) all use the same single of user interface equipment (keyboard, mouse, ...), but the equipment is only tied to one virtual terminal at a time. Yep, by switching virtual terminals, you're basically reassigning control of the equipment from one hardware terminal port to another. You might be doing something highly improbable, namely you are successfully running a "Hydra System" (i.e. multiple keyboards, mice, monitors, ... all connected to one system) -- If you've got that working, please tell me how. (; -- In this case you could have two different people logged in *locally* via UI equipment. Sadly, I do not recall how tty(4)'s and/or virtual terminals are assigned on a hydra system. I'm fairly certain it still involves the typicall TTY "dial-in" port waiting for a connection/login (via getty), but I do not recall (and can't find) the details on how the hardware gets assigned. In contrast, if you log in remotely via ssh, you use a "pseudo terminal" (pty(4)), so the local keyboard, mouse and whatever are not assigned. Again it might seem contradictory, but if you're running the X Window system, and you start an xterm window, the xterm is also assigned a pseudo terminal --the reason being is the keyboard, mouse and whatnot are *already* tied to the "Graphics Virtual Terminal" (/dev/X0 typically assigned to CTRL-ALT-F5) and the X Server is responsible for passing keystrokes to the xterm window. Yep, when you start X Windows, you actually switch virtual terminals, so the keyboard, mouse, monitor and whatever get reassigned to it. If you look at the default /etc/fbtab, you'll see it handles the reassignment of the your mouse device (/dev/wsmous /dev/wsmouse0). I do not personally know why only the mouse is reassigned to the X/Graphics virtual terminal via fbtab and your keyboard and monitor are not, but there is probably a good reason for it... ---I like to believe said good reason is sitting quietly, waiting, in a very large pile of good reasons that I do not know and need to discover. (; You've now got the basics of "login devices" (tty's/pty's), and you understand that using any one of the login devices can cause fbtab to change permissions on the system. At this point, you should see the potential "conflicts" you could create such as granting write access to the CDROM drive to two loging devices, and hence two different users. This supposed "conflict" is mostly imaginary. If you log in as root on two separate virtual terminals and try to format the one floppy disk on the system, guess what will happen? -Yep, one of them will get a "device busy" error and need to wait until the other is finished, so in most cases, it will not be a big deal. > It seems a lot simpler to just chmod g+w on any devices you find > you need and make sure you're in the operator group (though don't > chmod g+w /dev/*, I did that once and things broke very badly I seem > to recall, though I don't remember details since I was more like > "shitshitfixfix"). > > What's the risk in doing it this way? The only thing I can see is that > if someone breaks into your account they can burn CDs remotely If you're using the local tty's (/dev/ttyC?) to grant write access to the CDROM, you have a lot more to worry about because said attacker who "breaks into your account" has physical access to the machine. > (or overwrite any unmounted partitions) I see no reason to change hard disk permissions at all. The default permissions are correct just the way they are, and they prevent this kind of nonsense from unprivileged users. $ whoami jcr $ pwd /home/jcr $ mkdir jcr-mnt $ mount /dev/wd1a jcr-mnt mount_ffs: /dev/wd1a on /home/jcr/jcr-mnt: Operation not permitted $ > while you're not logged in which > is obviously so much more dangerous than someone breaking into your > account while you are logged in. > > -Nick That is a bold statement, particularly with the "obviously" you tossed in there, and with any bold statement, I would like to see your proof! I'll save you the effort; there is no proof. The thing you over-looked is the fact I said "local" user above. It's very useful for allowing read and/or write access to removable media (floppies, CD, maybe flash-drives if you're feeling generous) and/or sound/video devices without giving a user user excessive permissions (sudo and/or groups). Since the user has *physical* access to the machine in order to just use the removable media, the system is, by default, insecure. If a talented attacker has physical access to a machine, it's game over, you lose. Equally, if a talented attacker *only* has access to an unprivileged account remotely, it's still game over and you've still lost. Of course some moron on this list will say, "But I removed the compiler from the system so they can't write exploits," and everyone else here will sigh, mutter "fidiot" under their breath, and laugh... publicly. If said moron persists with his misconceptions, all the rest of us might get lucky enough to see beck@ put on his magical +5 Mullet Wig of Ranting and entertain us for a while. The situations where fbtab is very useful revolve around enabling an employee to do their job on a workstation, and doing so without granting excessive access to the machine. If said employee is actually a talented attacker in disguise, then you are, undoubtedly, hosed. The other situation where fbtab is very useful is when you do not trust *yourself* not to make a complete mess of your device permissions. If with excessive permissions you've ever executed the wrong command, or wrote a bit of code that goes running off into the weeds, and you've basically destroyed your OS installation by your mistake, then *you* are a perfect candidate for using fbtab... --Yes, that means every single one of us... including me. $ whoami jcr $ cdio tao install45.iso cdio: Can't open /dev/rcd0c: Permission denied $ The security implications of permissions on devices is an extremely complex topic. I probably understand maybe 20-30% of what I'd *need* to know to write/set them from scratch. Lucky for you, there are people a lot smarter than me who set all the default permissions up for you. If you decide to mess with them without understanding what you are doing, then you do so at your own peril. On the other hand, if you want to make an informed decision to grant read or write access to the CDROM drive or whatever of a workstation used by an employee, you now know you have options other than granting/requiring sudo or blindly tossing users into over-privileged groups or permanently changing your default device permissions on disk. -- J.C. Roberts
