> >> I think that the best way to do that is just run > the > >> commands and make > >> sure they fail appropriately when they can't be > run > >> and have that > >> error reported back., > >> > >> If not, you will have two implementations of > >> essentially the same access > >> mechanism and they are bound to drift out of sync > >> over time. > >> > >> Casper > > > >I can think of three reasons why a GUI could do a > better job if it knew in > >advance what was likely to be allowed: > > > >* it could alter the view it presented to only show > allowed functionality (or at least gray out > > that which was not allowed) > > > >* it could provide better indications of failure due > to privileges; even if it detected > > return codes and captured stderr for possible > display, doing things like parsing that > > captured output to provide detailed help would be > even more likely to break > > > >* it might sometimes be faster/more efficient to > detect in advance what would fail than > > to actually try and then have it fail. > > > Yes, but would it be worth the bugs? > > It is only sensible to implement it this way if there > was only a single > implementation used by both GUI and actual > implementation. > > If not, then coding this in the GUI makes no sense at > all as even > when it is done flawlessly today (it won't) the code > will be > wrong tomorrow.
Then add an option to pfexec that only checks if something should be permitted, returns zero/non-zero, and writes not a message, but a stable code that could be expanded to a message (so as to leave localization up to whatever reads that code) to its stdout. That would take care of things by doing everything but exec'ing the command, and by adding a code separate from the return code (which really shouldn't be more than zero/non-zero if I understand correctly) to provide further detail as to the error. Might as well create a library routine that takes care of calling that via popen() or whatever, too, allowing reasonably easy pre-validation, consistent with the actual checks, and with program-readable failure details. Or at any rate, whether it's implemented like that or some other way, IMO the RBAC framework itself ought to provide something with that sort of functionality. Again, I would expect that primarily GUIs would benefit from being able to adapt the options they presented in anticipation of permission issues. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
