Brian Utterback wrote: > > > Darren J Moffat wrote: > >> I'd like to hear from other ARC members on this but I feel that >> introducing a root package just for updating exec_attr is wasteful, >> even though it does mean putbacks to two consolidations. >> > > So, do I take the lack of further comment as assent? Is the plan to > simply add a line to exec_attr and forgo the *r package?
That is my strong preference but it seems no other ARC members are either listening or have an opinion on this that they wish to share. > By the way, does that have any ramifications for possible name > collisions? If as a nefarious evil genius bent on world domination, if I > wrote a FOSS package that happens to install (amongst other items) a > binary called "/usr/sbin/ngrep" that installs a rootkit when run as > root, would that amount to priv elevation if run by the network admin? Yes it would but that is in no way prevented by splitting the installation of this projects components over two packages. But then if you can get someone to install a package with a trojan horse ngrep why bother with exec_attr entries just make the trojan ngrep setuid, or even why bother with that you may was well just install the rootkit straight out of the package. > I guess I am asking if there is an issue with decoupling the exec_attr > line from the actual binary installation? No, and in many cases delivered by ON there are entries in the exec_attr file when the corresponding packages that deliver those binaries are not present. Also remember that your exec_attr table might not be local or even hosted on the same OS release so we already have that situation anyway. -- Darren J Moffat