On Mon, 31 Dec 2012 16:53:47 +0800 [email protected] wrote: > On Mon, 31 Dec 2012 10:03:40 +0200 > Alan McKinnon <[email protected]> wrote: > > > It's not in the profile, the xorg-server ebuild sets USE="suid" on > > by default. > > > > Most likely is that Walter has USE="-suid" in his make.conf and sets > > it back on for things he's checked out personally. Meaning that in > > this case one slipped through. > > I suspect it is a USE="-* (blah)" rather than an explicit USE="-suid" > in the make.conf file. > > One question though --- should the xorg-server ebuild be such that > IUSE="(blah) +suid" when using a hardened-profile?
That already has a de-facto answer; USE="suid" must be on by default as without it users cannot run a desktop (xorg-server does not yet run without root permissions) > Also, checking > my PORTDIR, given the global description in use.desc (suid - Enable > setuid root program, with potential security risks), shouldn't the > suid use flag entries (net-analyzer/nagios-plugins:suid and > net-wireless/kismet:suid) be deleted from use.local.desc? I see this is being discussed on -dev ATM. Duncan has this to say: "Promoting a flag to global does mean it gets a global description in use.desc, but per package descriptions (as now maintained in the per- package metadata.xml files, but there's a tree maintenance script that keeps use.local.desc current based on the metadata files, to keep the tools using it working) continue to be encouraged where they are useful, as they can often provide much more detailed per-package descriptions of what the flag actually does in that specific package, than the global description can." The current policy seems to be the sensible one: A global generic description can exist, but more specific package-level descriptions are also supported. I'd agree with that; a policy of "only global descriptions" or "no global description if a local one exists" would be overly restrictive and just cause problems. On the whole, we humans are perfectly OK with the idea of over-loading concepts; this is not something we have problems with. -- Alan McKinnon [email protected]
