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]
Date:	Thu, 10 May 2012 11:30:23 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Jan Kara <jack@...e.cz>
Cc:	Ludwig Nussel <ludwig.nussel@...e.de>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Rob Landley <rob@...dley.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	"open list:EXT2 FILE SYSTEM" <linux-ext4@...r.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH RESEND] implement uid and gid mount options for ext2,
 ext3 and ext4

On Thu, May 10, 2012 at 05:00:24PM +0200, Jan Kara wrote:
>   I've looked at this in more detail now. Although it would be nice to
> avoid duplicating the the functionality as others suggested, I agree it's
> not that simple and it seems to me we'd end up doing similar amount of work
> in the filesystems anyway (mount option parsing, writing to disk, printing
> mount options, ...). So I'm ok with the implementation as is and I'd be
> willing to take it for ext3 / ext2. But we really want to keep all ext?
> filesystems consistent so this also depends on Ted's approval of the change
> for ext4.  Ted?

Grumble.  I agree, reluctantly.  As much as I would like to make this
be generic, it looks like the amount of glue code to allow the VFS to
parse text-based mount options, and change the uid/gid fields after it
is read from disk and before writing to disk is probably more than the
code that we could be able to factor out.

>   What I'm missing in the changelog description is what i_diskuid/i_diskgid
> is good for. Although I can imagine some use case, I'm not sure I can see
> any sufficiently convicing one...

I'd much rather force diskuid and diskgid to 0 if the uid or gid is
specified, and if uid or gid option is in force, we force nosuid to be
on, to avoid the very obvious security problems if a sysadmin isn't
super careful.  The use case is going to be for things like USB sticks
where it's not likely that the sysadmin will be taking appropriate
care, so keeping things simple is probably a good thing.

>   Also please split the patch in three separate patches for ext2, ext3, and
> ext4. Thanks.

Yes, please.

							- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ