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:	Sat, 30 Jul 2011 11:14:16 +0200
From:	Jim Meyering <jim@...ering.net>
To:	Pádraig Brady <P@...igBrady.com>
Cc:	Matthias Schniedermeyer <ms@...d.de>,
	Luke Kenneth Casson Leighton <lkcl@...l.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>, Coreutils <coreutils@....org>
Subject: Re: ext3 hacked filesystem (by debian exim4 exploit) available for analysis and bugreporting

Pádraig Brady wrote:
...
> `strace lsattr ...` shows it calls ioctl (...FS_IOC_GETFLAGS...)
> So there would be overhead.
> The output of ls is fairly constrained too for compat reasons.

One way by which ls -l could inform us that a file has
"attributes" like that would be via what POSIX calls the
"optional alternate access method flag".  Currently,
it can be a space, a "+", or a ".":

Since coreutils-7.1 (Feb 2009), ls -l has been doing this:

    ls -l now marks SELinux-only files with the less obtrusive '.',
    rather than '+'.  A file with any other combination of MAC and ACL
    is still marked with a '+'.

Using other printable characters to denote attributes (trumping
SELinux, MAC and ACL settings) is possible.  Does any other ls
implementation already do that?  There would be the cost of the
additional ioctl... we'd have to measure that before deciding
whether to impose this on every use of ls -l.

Another possibility is to further overload the file type decorations
("*", "|", "="), that you see with -F.  Already, "*" is obviously
not a type indicator, so adding more attributes is not shocking.

> However these flags are not specific to ext2 so it would fit
> quite well from that perspective.
> It might be something we could add to the stat command at least?

Yes, this definitely deserves a new stat format directive or two.
At least one for each single-byte "attribute" described in chattr(1),
and maybe another for a readable string so we don't have to look up
the likes of "T" ("top" dir hint, for orlov block allocator) and
"t" (no-tail-merge).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ