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

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: <10655.1248384221@turing-police.cc.vt.edu>
Date:	Thu, 23 Jul 2009 17:23:41 -0400
From:	Valdis.Kletnieks@...edu
To:	Ludwig Nussel <ludwig.nussel@...e.de>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] implement uid mount option for ext2 and ext3

On Thu, 23 Jul 2009 13:36:29 +0200, Ludwig Nussel said:

> The following two patches (for 2.6.31-rc4) therefore implement the
> uid mount option for ext2 and ext3 to make them actually useful on
> removable media. My implementation just writes uid 0 to disk for
> files that are owned by the specified user.

I'm certain this will end up violating the Principle of Least Surprise.

For instance - you have UID 500 on 2 systems.  Mount on old system, create a
file - it's owned by 500.  Take it to a new system, mount it, watch it get
smashed to 0 because it's owned by "you".  Take it back to the old system, and
hey, you can't edit your file because it's not owned by 500 anymore...

Hint:  This *same exact* problem has been an issue for NFS for at least 25
years. Might want to think about (a) why Yellow Pages (and later LDAP) was
developed, and (b) why NFS "root squash" traditionally maps to "nobody" rather
than a usable UID.

Content of type "application/pgp-signature" skipped