Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 591022 - sys-apps/elfix: Provide one-line output format for paxctl-ng
Summary: sys-apps/elfix: Provide one-line output format for paxctl-ng
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-11 10:39 UTC by Klaus Kusche
Modified: 2016-08-11 13:55 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Kusche 2016-08-11 10:39:55 UTC
The multi-line-per-file output format of paxctl-ng is easy to read for humans,
but very hard to process automatically.

Please alternatively provide a one-line-per-file output format
which can be processed easily by standard unix text tools
(sort, diff, fgrep, cut, sed, ...).
Comment 1 Anthony Basile gentoo-dev 2016-08-11 11:17:00 UTC
(In reply to Klaus Kusche from comment #0)
> The multi-line-per-file output format of paxctl-ng is easy to read for
> humans,
> but very hard to process automatically.
> 
> Please alternatively provide a one-line-per-file output format
> which can be processed easily by standard unix text tools
> (sort, diff, fgrep, cut, sed, ...).

yeah good point, how would you like the format?  maybe something like


                      XATTR_PAX      PT_PAX
/usr/bin/python2.7    -E---          NF
/usr/bin/python3.4    NF             -E---


where NA means no flags were found - its better to have something in this field for scripts.
Comment 2 Klaus Kusche 2016-08-11 12:25:43 UTC
(In reply to Anthony Basile from comment #1)
> yeah good point, how would you like the format?  maybe something like
> 
> 
>                       XATTR_PAX      PT_PAX
> /usr/bin/python2.7    -E---          NF
> /usr/bin/python3.4    NF             -E---
> 
> 
> where NA means no flags were found - its better to have something in this
> field for scripts.

Happy with that.
Two things to discuss:

1. Should the filename be first or last (as in ls -l)?
Having it first makes sorting easier,
but having it last gives all three fields a fixed column
(if the filename is first, XATTR_PAX and PT_PAX will float to the right 
for long filenames).

2. I think NF or NA should be five special chars like ..... or ===== .
Reasons for that:
* Visually more outstanding
* Very unlikely to give false positives in filenames when being grepped for.
  (NF could appear in filenames and result in matches when being grepped).
Comment 3 Anthony Basile gentoo-dev 2016-08-11 13:44:12 UTC
(In reply to Klaus Kusche from comment #2)
> (In reply to Anthony Basile from comment #1)
> > yeah good point, how would you like the format?  maybe something like
> > 
> > 
> >                       XATTR_PAX      PT_PAX
> > /usr/bin/python2.7    -E---          NF
> > /usr/bin/python3.4    NF             -E---
> > 
> > 
> > where NA means no flags were found - its better to have something in this
> > field for scripts.
> 
> Happy with that.
> Two things to discuss:
> 
> 1. Should the filename be first or last (as in ls -l)?
> Having it first makes sorting easier,
> but having it last gives all three fields a fixed column
> (if the filename is first, XATTR_PAX and PT_PAX will float to the right 
> for long filenames).

Yes the file name should be last because the first two fields are fixed length and the file name isn't.

> 
> 2. I think NF or NA should be five special chars like ..... or ===== .
> Reasons for that:
> * Visually more outstanding
> * Very unlikely to give false positives in filenames when being grepped for.
>   (NF could appear in filenames and result in matches when being grepped).

After I wrote that, I realized it should be ----- that is 5 dashes.  The reason is again, you have fixed width fields.  So, if you want to know if EMUTRAMP is enabled, you just look at the second char in the 5 char sequence.  If its E then EMUTRAMP is on, if its e its off and if its - its whatever the default is.

My above example would be

XATTR_PAX      PT_PAX       FILE
-E---          -----        /usr/bin/python2.7
-----          -E---        /usr/bin/python3.4
-em--          -em--        /usr/bin/very-long-file-name

The only last point is, do we add a switch so we can have both outputs, or just change the default to the above.  I think just use the above since its both human readable and script friendly.
Comment 4 Klaus Kusche 2016-08-11 13:55:34 UTC
(In reply to Anthony Basile from comment #3)
> > 2. I think NF or NA should be five special chars like ..... or ===== .
> > Reasons for that:
> > * Visually more outstanding
> > * Very unlikely to give false positives in filenames when being grepped for.
> >   (NF could appear in filenames and result in matches when being grepped).
> 
> After I wrote that, I realized it should be ----- that is 5 dashes.  The
> reason is again, you have fixed width fields.  So, if you want to know if
> EMUTRAMP is enabled, you just look at the second char in the 5 char
> sequence.  If its E then EMUTRAMP is on, if its e its off and if its - its
> whatever the default is.
> 
> My above example would be
> 
> XATTR_PAX      PT_PAX       FILE
> -E---          -----        /usr/bin/python2.7
> -----          -E---        /usr/bin/python3.4
> -em--          -em--        /usr/bin/very-long-file-name

Hmmm, that's fine for XATTR_PAX, because XATTR_PAX should never be present,
but empty (is that so? Is XATTR_PAX deleted or set to empty when an existing XATTR_PAX is reset to default?), 
but I think we need some way to distinguish between
"present, but default (no flags set)" and "no PT_PAX header in file", 
because both can legally exist and it makes a difference when handling the file.

> The only last point is, do we add a switch so we can have both outputs, or
> just change the default to the above.  I think just use the above since its
> both human readable and script friendly.

For me, single line is sufficient.