>>>>> "Jamie" == Jamie Lokier <jamie@xxxxxxxxxxxxx> writes: Sorry for the delay, I was out of it this weekend... :] Jamie> John Stoffel wrote: >> I didn't read the original email closely, but I have to say that both >> of these plans don't sound good to me. If you can mount a filesystem, >> you're root already, so you can do any fixup you need. Jamie> What if someone lends you a 1TB disk, for you to browse it in Jamie> your favourite GUI or Shell Window to read some files from it? Jamie> And you're to put a couple of files on it before you give it Jamie> back? So? How is the kernel supposed to know you're doing this? Jamie> Hotplug scripts run as root to mount it, and you have your GUI Jamie> / Shell Window which don't run as root to read and write a few Jamie> of those files. Jamie> You must not chown anything on the disk, because it isn't your Jamie> disk. Umm... this doesn't make sense. If it's not your disk, why are you writing to it? And how is chown different? The real answer is that your buddy should have setup a mode 777 directory on there where random stuff could be dropped. Again, a userspace issue, not kernel. >> But in that case, you're screwed anyway and it's going to become >> un-manageable. Push this to userspace, not the kernel since it's a >> userspace issue when you come right down to it. Jamie> How do you handle the above scenario in userspace? You certainly can't handle this in kernel space! If you just plug in a random disk, and it comes up with borked UIDs because the original server it came from has a different setup than yours for UID/GIDs, then you're going to have to do *something* in a manual manner to fix it. Either you need to 'sudo chown -R user /media/disk/' or better yet just mkdir a new directory with appropriate permissions and then write using your GUI/shell-window, non-root user account to that new directory. Putting in a mount option like this is just begging for all kinds of issues. John -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html