linux-kernel - Re: [PATCH 1/2] implement uid mount option for ext2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19053.49157.984140.286148@stoffel.org>
Date:	Mon, 27 Jul 2009 10:56:05 -0400
From:	"John Stoffel" <john@...ffel.org>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	John Stoffel <john@...ffel.org>, Andreas Dilger <adilger@....com>,
	Ludwig Nussel <ludwig.nussel@...e.de>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] implement uid mount option for ext2

>>>>> "Jamie" == Jamie Lokier <jamie@...reable.org> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/