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:	Mon, 13 May 2013 09:37:31 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Mike Frysinger <vapier@...too.org>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] mke2fs: do not change root dir ownership

On Mon, May 06, 2013 at 05:21:56PM -0400, Mike Frysinger wrote:
> If you use `mke2fs` on a file, the code will automatically chown the root
> dir to the active uid/gid.  It doesn't do this to any other files though.
> 
> I can't see where this would really be desirable: you still need root in
> order to mount, and the lost+found dir is owned by root.  It means if you
> want to generate a rootfs as a non-root user, you first have to run it
> through sudo or manually run `chown 0:0` after you've mounted it.

Yeah, this was something that we've been doing in e2fsprogs since 0.5b
(i.e., dating back to 1997).  I agree that the behavior is a bit silly
and we should probably change it.  It *is* a behavioural change,
though, so I'm going to make it something that changes in 1.43, as
opposed to a 1.42.x maintenance release.

A workarond that I'd recommend (since we will have lots of people
creating file systems for various mobile/embedded systems, and they
will have scripts that need to work on existing versions of e2fsprogs)
is to do something like this:

   mke2fs -t ext4 /tmp/foo.img 16384
   debugfs /tmp/foo.img -R "set_inode_field / uid 0"
   debugfs /tmp/foo.img -R "set_inode_field / gid 0"

   	   		   		      	  - 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