Re: semanage cleanup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Better help text is always a good thing, using a standard way of processing data is also good.

Semanage-fcontext doesn't seem to give any real benefit over "semanage fcontext" though.

David Quigley <dpquigl@xxxxxxxxxxxxxxx> wrote:
I've given a few talks on SELinux over the past year and I've spoken to 
a bunch of people on google+ about SELinux and one topic keeps coming
up. Many people find semanage to be large and convoluted with the help
text being way to large to sort through. The latter part of the
complaint is easy to address. The code for argument parsing in semanage
(last time I checked) doesn't use things like argparse. If we switched
it over to argparse we could get per sub-command help messages that
would be more useful to people when they messed up a sub-command. Would
anyone be opposed if I spent the time to migrate semanage argument
parsing and help messages over to argparse or a similar library?

The second problem some people have is that semanage is a multiplexed
command. I'm not sure what the right way to approach this is. If we look
at other applications which are multiplexers we get a few examples.
Busybox is the first example and covers most of the discussion. The two
ways of invoking busybox is either busybox command_name arguments or
command_name arguments where command_name is a symlink to the busybox
binary. If we chose the latter way of handling it we would need to
decide on one of two ways of naming the sub-commands. The first method
would be to come up with a naming convention for the subcommands to
avoid collisions like selogin for semanage login or seusers for semanage
users etc. The second method would be to do what git use to do which is
prepend the tool name onto the subcommand. For example
semanage-fcontext, semanage-login, semanage-users etc... If we chose
this route then we'd need to investigate what git's reason for moving
away from it was and decide if it applies to our situation as well.

If we convert over to argparse for argument parsing it should be
trivial to do some processing on argv[0] to extract out a subcommand
from a name and use the correct routines. I'm not sure that solving the
second problem gets us substantial gains or if having help messages that
are specific to each subcommand will help users more.

Does anyone have any thoughts about this?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

--
My blog http://etbe.coker.com.au
Sent from an Xperia X10 Android phone with K-9 Mail.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux