[Toybox] [NEW TOYS] hardware rescan tool, FIFREEZE/FITHAW wrapper

[Isaac Dunham]

On Tue, Apr 01, 2014 at 08:04:55AM -0500, Rob Landley wrote:
> On 03/29/14 02:22, Isaac Dunham wrote:
> > I've written a couple of new toys that might well be out of
> > scope, but might be interesting or useful "for parts".
> >
> > I'll describe the commands and the use cases.
> 
> Ok.
> 
> > 1-hwrs:
> > This was originally intended as a SUID helper cludge for my
> > Acer Aspire One, which has a PCI-bus based SD card reader
> > that only shows up when the SD card is inserted. Kernel PCI
> > hotplug does not work properly, with the card reader frequently
> > failing to show up, dmesg getting spammed when I enable it,
> > and the wireless card sporadically failing for reasons that
> > seem to be related. However, it works to manually trigger a
> > PCI bus rescan. Additionally, neither mdev nor udev (as
> > configured in Debian Squeeze)  probe for partitions on slow
> > external media, which makes configuring a  user mount in
> > /etc/fstab pointless.
> 
> They just respond to hotplug events.
> 
> The toybox mdev is only halfway implemented, and part of the
> reason is devtmpfs exists now, so half of what mdev used to
> do is unnecessary. It needs a bit of a redesign, and I haven't
> gotten around to looking hard it since.
> 
> > I didn't want to have to log in as root every time I plugged
> > in an SD card, so I wrote this. It simply triggers a PCI bus
> > rescan (hwrs -p), then walks /dev opening every block device
> > so as to make the kernel look for partitions (hwrs -b).
> 
> This does strike me as an mdev function... except that mdev isn't
> currently an suid command. Normal users can't trigger any useful
> behavior out of mdev, and trying to add that capability opens fun holes
> where mdev is called as /sbin/hotplug and does something based on
> environment variables...
> 
> I can distinguish suid from actual root via getuid() != geteuid() and
> just have TOYBOX_STAYROOT without TOYBOX_NEEDROOT and then do the "if
> (!geteuid() && getuid() && setuid(getuid())) perror_exit("setuid");"
> dance that main.c is currently doing. (I'm aware this ignores capability
> bits, and am actually pretty happy about that.)

> > Default behavior is the same as hwrs -pb.
> > The sole reason I wrote it as a new toy was that was the
> > quickest way to get it done.
> >
> > If you think that this isn't in scope but the probe for
> > partitions sounds interesting for mdev, I'd be happy to write
> > that.
> 
> I think a command line option to tell mdev to give the PCI bus a good
> smack and then rescan all the block devices sounds fine. It's not the
> default behavior, but an mdev command line option (possibly with a
> config option) is probably where this belongs.

I was thinking that the PCI bus rescan belonged somewhere else; if the
open() magic is done when we get a block device via mdev -s or hotplug,
we won't need suid for that.
The thought is that mdev responds to kernel events; it doesn't create
them at present.

> > (Coincidentally, I've thought of a way to make mdev
> > handle hotplugging with minimal code changes: use the environment
> > to find the right uevent file.)
> 
> The one I wrote for busybox did hotplugging. The busybox one has changed
> a huge amount since then and I want to read up on it to see if people
> have expectations. I also want to make it work well with devtmpfs.

The big one I can think of is  the move/rename/execute command syntax
after field 3.
Eg (from my mdev.conf, copied from Alpine):
ram([0-9]*) root:disk  0660 >rd/%1
card[0-9]   root:video 0660 =dri/
fb[0-9]     root:video 0660 @chown root:video $MDEV && chmod 660 $MDEV
usbdev[0-9].[0-9]  root:root 0660 */lib/mdev/usbdev

> I also need to figure out what horrible things <strike>devfsd</strike>
> <strike>hald</strike> systemd is doing in this area, so I can obsolete them.
> 
> > 2. xfs_freeze:
> > This is only a wrapper for the FIFREEZE/FITHAW ioctls.
> 
> man 8 fsfreeze
> 
> Apparently part of util-linux since 2010 or so.

Oh, just after Lucid and Squeeze froze.
Which would be why I didn't know about that.

> > The name is a historical artefact; this is a clone of the
> > xfs_freeze utility from xfsprogs.
> 
> I renamed it to the generic one. (Then hit some strange command line
> option parsing bug I need to fix when testing it, so haven't checked it
> in yet...)

> Thanks,
> 
> Rob

Thank you,
Isaac Dunham

 1396452825.0