Package: pysudoers
pysudoersThis library provides aPythoninterface to the Linux sudoers file.  python-sudoers is open sourced under theBSD 3-Clause license.Basicspysudoersruns onPython>= 3.6FeaturesThis library parses a sudoers file into its component parts.  It's not 100% compliant with the EBNF format of the file (yet), but it's getting there.  Currently, the script parses out 6 distinct line types from the file:Defaults (This is only a string currently.  Pieces of a Defaults setting are not parsed/separated.)Cmnd_AliasHost_AliasRunas_AliasUser_AliasUser specifications (which we callrules)As user specifications are the most complicated, they are most likely the area that needs the most improvement.  Currently, the following pieces of a user specification are separated out as part of the parsing:User listHost listCommand list (containing):TagsRun As notationsCommandsInstallingYou can use pip to install pysudoers:pipinstallpysudoersExamplesParsing of thesudoersfile is done as part of initializing theSudoersobject.  So, you can start using the properties underSudoersimmediately.  The following example will print out all the different "types" from the file:frompysudoersimportSudoerssobj=Sudoers(path="tmp/sudoers")fordefaultinsobj.defaults:print(default)forkeyinsobj.host_aliases:print(key)print(sobj.host_aliases[key])forkeyinsobj.cmnd_aliases:print(key)print(sobj.cmnd_aliases[key])forkeyinsobj.runas_aliases:print(key)print(sobj.runas_aliases[key])forkeyinsobj.user_aliases:print(key)print(sobj.user_aliases[key])forruleinsobj.rules:print(rule)Now, suppose you want to print out all the user specifications (rules), but you only want to see the users and hosts for each rule.frompysudoersimportSudoerssobj=Sudoers(path="tmp/sudoers")forruleinsobj.rules:print("%s|%s"%(",".join(rule["users"]),",".join(rule["hosts"])))ContributingPull requests to add functionality and fix bugs are always welcome.  Please check the CONTRIBUTING.md for specifics on contributions.TestingWe try to have a high level of test coverage on the code.  Therefore, when adding anything to the repo, tests should be written to test a new feature or to test a bug fix so that there won't be a regression.  This library is setup to be pretty simple to build a working development environment usingDocker.  Therefore, it is suggested that you haveDockerinstalled where you clone this repository to make development easier.To start a development environment, you should be able to just run thedev.shscript.  This script will use theDockerfilein this repository to build aDockercontainer with all the dependencies for development installed usingPoetry../dev.shThe first time you run the script, it should build theDockerimage and then drop you into the container's shell.  The directory where you cloned this repository should be volume mounted in to/usr/src, which should also be the current working directory.  From there, you can make changes as you see fit.  Tests can be run from the/usr/srcdirectory by simply typinggreenasgreenhas been setup to with the correct parameters.ChangelogTo generate theCHANGELOG.md, you will needDockerand a GitHub personal access token.  We currently usegithub-changelog-generatorfor this purpose.  The following should generate the file using information from GitHub:dockerrun-it--rm\-eCHANGELOG_GITHUB_TOKEN='yourtokenhere'\-v"$(pwd)":/working\-w/working\ferrarimarco/github-changelog-generator--verboseTo generate the log for an upcoming release that has not yet been tagged, you can run a command to include the upcoming release version.  For example,2.0.0:dockerrun-it--rm\-eCHANGELOG_GITHUB_TOKEN='yourtokenhere'\-v"$(pwd)":/working\-w/working\ferrarimarco/github-changelog-generator--verbose--future-release2.0.0--unreleasedReleasesReleases to the codebase are typically done using thebump2versiontool.  This tool takes care of updating the version in all necessary files, updating its own configuration, and making a GitHub commit and tag.  We typically do version bumps as part of a PR, so you don't want to havebump2versiontag the version at the same time it does the commit as commit hashes may change.  Therefore, to bump the version a patch level, one would run the command:bump2version--verbose--no-tagpatchOnce the PR is merged, you can then checkout the newmainbranch and tag it using the new version number that is now in.bumpversion.cfg:gitcheckoutmain
gitpull--rebase
gittag1.0.0-m'Bump version: 0.1.0 → 1.0.0'gitpush--tags