linux-ext4 - Re: [e2fsprogs] initdir: Writing inode after the initial write?

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: <50BE51BF.6020208@infradead.org>
Date:	Tue, 04 Dec 2012 11:40:47 -0800
From:	Darren Hart <dvhart@...radead.org>
To:	Theodore Ts'o <tytso@....edu>
CC:	Andreas Dilger <aedilger@...il.com>,
	Andreas Dilger <adilger@...ger.ca>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [e2fsprogs] initdir: Writing inode after the initial write?

On 12/04/2012 11:08 AM, Theodore Ts'o wrote:
> On Tue, Dec 04, 2012 at 09:43:21AM -0800, Darren Hart wrote:
>>> "modify_inode" is not a terribly easy use interface. Probably better to add something like "chmod" and "chown" for debugfs as well.
>>
>> I was thinking the same thing.
>>
>
> modify_inode is the old command, and it is indeed hard to use.  The
> new one (and the one I use all the time) is set_inode_field
> (abbreviation "sif"):
>
>     sif /bin/su mode 0104755
>     sif /bin/su uid 0

Ah, excellent.

> BTW, one of the things that I've always toyed with was to create a
> shim layer between the libss API and the tcl embedding API, which
> would add some scripting, aliases, and automation relatively easily to
> debugfs.
>
> What people have done in practice who have cared about this is to
> create perl scripts which emits a series of commands which they then
> feed to a pipe which has debugfs on the other end.

And this is what Andreas suggested with the example bash script. I may
convert
this to a python script, but the concept is sound. That said, I still
feel that
a logical approach would be the following:

1) Update debugfs to completely support our use-case
   [ ] Add symlink support
   [ ] Add hardlink support
   [ ] Add meta-data mirroring
   (some of this belongs in the script and not in the ext2fsprogs)
2) Refactor filesystem creation functions from debugfs and move them into
   libext2fs alongside existing filesystem creation functions like
   ext2fs_mkdir()
3) Add the "-r initialdir" option to mke2fs that leverages these new
functions
   from libext2fs.

#3 makes for a more consistent filesystem creation process across
filesystems.

Does this seem like a reasonable approach? Any objection to the migration of
code into libext2fs?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
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