Hi. On Sat, 29 Oct 2016 19:15:53 +0100 Brian <a...@cityscape.co.uk> wrote:
> On Sat 29 Oct 2016 at 18:48:11 +0300, Reco wrote: > > > On Sat, 29 Oct 2016 15:09:09 +0100 > > Brian <a...@cityscape.co.uk> wrote: > > > > > On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote: > > > > > > > On Sat, 29 Oct 2016 08:16:18 -0400 > > > > rhkra...@gmail.com wrote: > > > > > > > > > I'll say that the wiki page gave no hint as to which of the three > > > > > options to > > > > > install, or any hint that one might work better than another. > > > > > > > > The page is describing 'Producing an automated install of a Debian > > > > operating system from a USB stick', to quote it. For such an advanced > > > > task it can be safely assumed IMO that the person who's implementing the > > > > instruction is familiar with the basic concepts of a 'file system' or > > > > 'mounting'. > > > > > > The question of providing guidance on which of the three tools to use is > > > an interesting one. As far as possible a wiki page like this one should > > > stick to facts and technical matters; venturing into the area of opinion > > > isn't the way to go, IMO. Do any of these tools have a distinct > > > technical advantage for the purpose of installing GRUB is the question > > > to ask and answer? If the answer is "no" don't they deserve equal > > > exposure? > > > > No advantage that I'm aware of. In fact, the whole paragraph could be > > shortened to already existing text: > > > > If you are working within one of the desktop environments it is very > > likely the mounting can be done from he file manager which comes with > > it. This is because udisks2 will be on the system. A label will > > possibly be used for the mount point. > > I wish you had addressed the "equal exposure" question. Desktops are not > the only environments in town. Leaving non-policykit users out in the > cold is not an option. True, that does not look good at all. But why bother listing udisks2 which is using PolicyKit then? Besides, in modern Debian it takes a certain amount of skill and determination *not* to use PolicyKit ;) > > > The tools exist and all can be assumed to work. The choice of which one > > > to use is up to the user. For many users a couple of clicks on a desktop > > > will get the stick mounted; others might like the challenge of using a > > > new tool. > > > > My point exactly. Why bother naming all these tools if it all comes down > > to "you might use your file manager to do this part for you as well"? > > It doesn't come down to that; using a desktop filemanager is just one of > the alternatives. One could equally well ask why it is has to mentioned > when there is > > > Install pmount, udevil or udisks2 and use one ..... Indeed. All this confusion could be avoided by simple 'please mount the USB stick to this mountpoint'. Again, the page describes rather advanced topic. > Providing a range of advice for a range of people isn't exactly easy in > all situations. Advice on installing a wifi kernel module is easy - > there is only one for each chipset. I honestly wish that this was true. Sadly, there's Broadcom, see [1] for the gory details. > A page on pmount is a little harder because it is a moving target. I honestly lost you here. oldstable, stable, testing and even sid have the same upstream version of pmount - 0.9.23, dated 2010. > (The link you gave has out-of-date info on HAL). Anything more > complex can always be criticised as time moves on. The page itself is somewhat outdated, true. Someone should cleanup that obsolete hal reference. > But your sort of constructive criticism is valuable. You're welcome, I guess. > > > A few might say - "Hey, interesting, never knew about that; > > > I'll give it a go". And then go on to use it in another context. > > > > True, but why stop here? Author(s?) of the page might mention usbmount > > and supermount as well. > > You are getting carried away here. Both are for *automatically* mounting > and unmounting removable media, which is not a focus for the task. > > There is no sign of supermount in stable or unstable. True. That's something that I missed. > > > > It can be argued (again IMO) that the 3 tools proposed are not the best > > > > ones available for the task, or downright redundant due to availability > > > > of mount(8), but all three mentioned tools are in fact are links to [2]. > > > > Broken ones (for me at least), but they are links to manpages for the > > > > mentioned tools. Surely a manpage can be viewed as a suitable source of > > > > hints you're referring to. > > > > > > mount is a root-only tool; the others aren't. Need I say more? > > > > Yes, I believe you do. > > As little as possible should be done as root is a good principle. mount(2) system call is a privileged one regardless of the tool used. Hence a root intervention in one form or the other is needed. Whenever such privilege escalation is done by trusted daemon (udisks2), or by hand (su, sudo) for the purposes of mounting and unmounting is not relevant. Assuming, for the sake of simplicity, that all implementations of privilege escalation (su, sudo, policykit, trusted suid binaries such as pmount) are free of security bugs. If it was desirable to exclude root intervention whenever possible in this task - the page in question would suggest fusefat instead. > > The page mentions 'Check the mount point from within the fie manager or > > with the command "mount"' (curious typo btw), rightfully assuming that > > one does not need to be root to do that. > > C'mon; pointing out a typo! This is unworthy of you, even as an aside. Disregard the typo comment then as it was not pointed to the article quality. Not all mount(8) invokations require root, that was the point. > > > > > Of course, > > > > > until this issue came up, no one may have expected one to work better > > > > > than > > > > > another, so then someone reading that page could, quite > > > > > appropriately, try one > > > > > and not the others, and assume that there was no more useful > > > > > information on > > > > > the page. > > > > > > > > I agree that the page provides unnecessary choice in this regard, and > > > > for the sake of clarity of this topic [3] would be more appropriate. > > > > > > Fair enough. But why not udisks2? After all, it will already be on many > > > machines. > > > > No reason, really. pmount was mentioned first on the page. > > Mounting and unmounting are not really a problem. Users and root can > easily do these. But, as far as I can see, only someone with root > privileges can use dd, cfdisk, fdisk and mkfs.vfat with a removable > device. I'd like to be wrong. This is a common myth that I'll debunk gladly. Image copying (dd or any other tool) merely requires ability to write to a block device. Such permissions on removable media should be provided to any current console user by logind (or ConsoleKit if we still need to think about wheezy), or a good old-fashioned 'floppy' (any group name will do) group and a custom udev rule (as of jessie). Creating any filesystem on a removable media's partition merely requires the same. Changing a partition table (as in 'bytes on media') require an ability to both read and write from/to block device. Ditto. Changing what current kernel thinks of the partition table (as in 'kernel state') is privileged indeed, but it can be worked around by a simple yanking/putting back. Failing that there's always a possibility to reboot a host (a dirty trick, I know ;). Reco
