e2fsprogs icon indicating copy to clipboard operation
e2fsprogs copied to clipboard

Support for extended attributes and big UID/GID using debugfs rdump

Open MQueiros opened this issue 4 years ago • 2 comments

It seems debugfs rdump command lacks the ability to extract extended attributes and big UID/GID automatically.

Example:

# Expected file attributes
drwxrwxr-x.  3  4012201  4012300 u:object_r:system_data_file:s0 4.0K Feb  8 16:58 dummy_file

# Attributes obtained using debugfs rdump
$ debugfs -R "rdump / mount_dir/" image.ext4
drwxrwxr-x  3    14505    14604 ? 4.0K Feb  8 16:58 dummy_file

Note that rdump reads "14505:14604" instead of "4012201:4012300" and also doesn't read extended attributes

Both uid/gid and extended attributes can be obtained using some additional commands:

# Get uid/gid
debugfs -R 'ls -l' image.ext4
# Get extended attributes
debugfs -R 'ea_list dummy_file' image.ext4

, which then require additional parse commands.

Having support for extracting that info with the "debugfs rdump" command would be very useful

MQueiros avatar Feb 24 '21 16:02 MQueiros

Yeah, there are multiple bugs here, most of which are caused by the fact that rdump hasn't been updated since the days of ext2/ext3:

  1. rdump only understands 16-bit uid's and gid's
  2. rdump doesn't support extended attributes
  3. rdump doesn't support POSIX acl's

The first is trivially easy to fix. The second two will be quite a bit more work to add code to support. And even then, we're only going to be able to support user-visible extended attributes. Certain system xattrs, such as SELinux's security id, are not going to be easily supported, since there aren't userspace interfaces to set system xattrs, and even if there were, it's likely the user running debugfs won't have the necessary security authorizations to be able to willy-nilly set internal SELinux state.....

I agree having support in rdump for user xattr's and acl's would be nice. Patches will be gratefully accepted. :-)

tytso avatar Feb 24 '21 18:02 tytso

I understand :) For now, I'm using the workaround successfully ("ls -l" and "ea_list"). If I come across this again in the future, I may try to provide patches :)

MQueiros avatar Feb 25 '21 10:02 MQueiros