On 22 February 2015 at 15:35, Daniel Campbell <cont...@sporkbox.us> wrote:
> > > > Personally, I think that controlling who is allowed to run certain > > types of applications via group membership is a great idea. We > > should introduce that approach for other applications too. How > > about an "editors" group? Text editors are potentially dangerous > > because they allow users to modify files. Therefore, the system > > administrator should add only trusted users to the "editors" group > > so they can run programs like emacs, nano, or vim from the > > app-editors category. > > > > Ulrich > > > I hadn't thought of that! Would testing that idea require much beyond > creating the group, adding users, and chmodding the binaries? It seems > like it'd make a good USE option for those running servers with strict > permission needs. Then again, isn't that what LDAP or ACL are designed > to handle? Surely, there should be a straight foward way to do that via env.d + package.env ? env.d/restrict-editors.conf: PORTAGE_INST_GID=editors # this one exists PORTAGE_INST_BIN="ug+x,o-x" # this one does not or even PORTAGE_BIN_DIR="/usr/bin/editors/" # and then just set perms on the dir itself, but this doesn't exist yet + package.env: app-editors/* restrict-editors.conf That combination would give the flexibility needed without having to have portage implicitly bake all that logic into the whole tree. ( And it would make it available to usecases we haven't envisioned yet ) I half considered Urlich to be joking .... but either way, I'm quite capable of running with it and seeing where that leads us =). Just seems that this type of isolation is really not necessary generally and having it visible in a general purpose way is more prone to make life difficult for both developers and users. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
