Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On Sunday 23 March 2008, Alon Bar-Lev wrote: linux-2.6.24 supports file based capabilities via: CONFIG_SECURITY_FILE_CAPABILITIES This enables the use of filesystem attributes in order to store per executable capabilities list, more information at [1]. This enables improved security level for people who don't wish to move into SELinux or similar. I think a new global USE flags (or use current caps) may enable ebuilds to set correct capabilities on files. Diego and i were talking ... we're going to go with USE=filecaps because it's so new and doesnt require the libcap library in order to work at runtime. probably be worthwhile to put together a little eclass of functions to make people's lives easier ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-power/nut: ChangeLog nut-2.2.1.ebuild
On Saturday 15 March 2008, Donnie Berkholz wrote:
On 06:03 Sun 09 Mar , Rajiv Aaron Manglani (rajiv) wrote:
1.1 sys-power/nut/nut-2.2.1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-power/nut/nut-2.2.1.e
build?rev=1.1view=markup plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-power/nut/nut-2.2.1.e
build?rev=1.1content-type=text/plain
src_install() {
...
eval fperms 0640 ${NUT_PRIVATE_FILES}
eval fowners root:nut ${NUT_PRIVATE_FILES}
eval fperms 0644 ${NUT_PUBLIC_FILES}
eval fowners root:root ${NUT_PUBLIC_FILES}
...
pkg_postinst() {
# this is to ensure that everybody that installed old versions still has
# correct permissions
chown nut:nut ${ROOT}/var/lib/nut 2/dev/null
chmod 0700 ${ROOT}/var/lib/nut 2/dev/null
eval chown root:nut ${ROOT}${NUT_PRIVATE_FILES} 2/dev/null
eval chmod 0640 ${ROOT}${NUT_PRIVATE_FILES} 2/dev/null
eval chown root:root ${ROOT}${NUT_PUBLIC_FILES} 2/dev/null
eval chmod 0644 ${ROOT}${NUT_PUBLIC_FILES} 2/dev/null
Is there any reason why eval is used in either of these places?
i'd open a bug so it doesnt get lost
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/24/08, Mike Frysinger [EMAIL PROTECTED] wrote: Diego and i were talking ... we're going to go with USE=filecaps because it's so new and doesnt require the libcap library in order to work at runtime. probably be worthwhile to put together a little eclass of functions to make people's lives easier ... Great!!! You write eclass, me start patching ebuilds and open bugs against maintainers :) Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On Mon, 24 Mar 2008 14:27:39 +0200 Alon Bar-Lev [EMAIL PROTECTED] wrote: On 3/24/08, Mike Frysinger [EMAIL PROTECTED] wrote: Diego and i were talking ... we're going to go with USE=filecaps because it's so new and doesnt require the libcap library in order to work at runtime. probably be worthwhile to put together a little eclass of functions to make people's lives easier ... Great!!! You write eclass, me start patching ebuilds and open bugs against maintainers :) Uh, you missed out the whole new EAPI step. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On Monday 24 March 2008, Alon Bar-Lev wrote: On 3/24/08, Mike Frysinger [EMAIL PROTECTED] wrote: Diego and i were talking ... we're going to go with USE=filecaps because it's so new and doesnt require the libcap library in order to work at runtime. probably be worthwhile to put together a little eclass of functions to make people's lives easier ... Great!!! You write eclass, me start patching ebuilds and open bugs against maintainers :) eclass wrapping will also allow us to abstract away the fun OS details, but we'll start with linux for now. how much do we want to help the user ? if they have USE=filecaps, then dont perform any checking ? we'll need a kernel with file capabilities turned on, otherwise the prog wont work unless it's setuid ... so do we perform checking and drop the setuid bit on the post sly ? i'd prefer we just make the filecaps desc verbose: dont set this unless you have new enough kernel with options enabled, otherwise things may stop working properly as non-root. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/24/08, Mike Frysinger [EMAIL PROTECTED] wrote: how much do we want to help the user ? if they have USE=filecaps, then dont perform any checking ? we'll need a kernel with file capabilities turned on, otherwise the prog wont work unless it's setuid ... so do we perform checking and drop the setuid bit on the post sly ? i'd prefer we just make the filecaps desc verbose: dont set this unless you have new enough kernel with options enabled, otherwise things may stop working properly as non-root. I also prefer descriptive warning and not runtime checks. Worse case scenario, system will be usable for root only. root can remove this USE flag and emerge --update --deep --newuse world. Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: Fw: [gentoo-dev] Gentoo Enterprise 10000 support and developer access
Date: Sat, 22 Mar 2008 13:33:14 -0400 From: Mike Spenard [EMAIL PROTECTED] To: gentoo-dev@lists.gentoo.org Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [gentoo-dev] Gentoo Enterprise 1 support and developer access Raúl-Ferris, This past week I made an e10k I own/operate accessible [i.e. the SSP] to Mark Kettenis the OpenBSD-sparc maintainer. And Mark added support for the Sun Enterprise 1 (SMP and e10k RTC support). Theo thought it was very beneficial as a few bugs effecting other systems were picked up in the process. I thought I would extend the opportunity to the Gentoo-sparc team. Mike Spenard - -- gentoo-dev@lists.gentoo.org mailing list Mike, Thanks for the offer. Currently, we do have access to a system at OSL for sparc development and probably do not need access to yours. However, I am making sure that everyone on the sparc team sees that your system is available in case any individual can use your specific configuration. We ourselves really do very little kernel work and probably cannot use it for that. It is possible, though, that your system can be useful when we find issues which are system-specific, in which case you can expect to hear from us further. I do not know how you use your system or what operating system you usually have running on it. If you happen to run Gentoo/linux on it and wish to become involved in our sparc project, I invite you to read about the Architecture Testing program at http://www.gentoo.org/proj/en/base/sparc/at/index.xml and consider if you are interested in that. Thangs again, and Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: Fw: [gentoo-dev] Gentoo Enterprise 10000 support and developer access
Ferris McCormick wrote: Date: Sat, 22 Mar 2008 13:33:14 -0400 From: Mike Spenard [EMAIL PROTECTED] To: gentoo-dev@lists.gentoo.org Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [gentoo-dev] Gentoo Enterprise 1 support and developer access Raúl-Ferris, This past week I made an e10k I own/operate accessible [i.e. the SSP] to Mark Kettenis the OpenBSD-sparc maintainer. And Mark added support for the Sun Enterprise 1 (SMP and e10k RTC support). Theo thought it was very beneficial as a few bugs effecting other systems were picked up in the process. I thought I would extend the opportunity to the Gentoo-sparc team. Mike Spenard - -- gentoo-dev@lists.gentoo.org mailing list Mike, Thanks for the offer. Currently, we do have access to a system at OSL for sparc development and probably do not need access to yours. However, I am making sure that everyone on the sparc team sees that your system is available in case any individual can use your specific configuration. We ourselves really do very little kernel work and probably cannot use it for that. It is possible, though, that your system can be useful when we find issues which are system-specific, in which case you can expect to hear from us further. I do not know how you use your system or what operating system you usually have running on it. If you happen to run Gentoo/linux on it and wish to become involved in our sparc project, I invite you to read about the Architecture Testing program at http://www.gentoo.org/proj/en/base/sparc/at/index.xml and consider if you are interested in that. Thangs again, and Regards, Ferris Hi Ferris, Currently the diskless boot image bombs, and another e10k user I know hasn't been able to install Gentoo on his machine via cdrom either. Could you put me in touch with someone that can do linux-sparc kernel and diskless boot image development? Thanks, Mike -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Doug Goldstein wrote: It appears my migration plan was not good enough for Mike Frysinger [EMAIL PROTECTED] and he went ahead and wrote his own version of the OpenRC ebuild, differing from the one in the OpenRC layman repo, and committed it to the tree this weekend. Since my offer to work on the migration was not good enough for him, I'm backing out and allowing him to handle the whole migration himself since I haven't heard from him at all despite Roy (author of OpenRC) and my attempts to contact him for 2 weeks regarding a migration plan for OpenRC. All issues and comments can be directed to him. I guess working together and documenting everything before having it hit the tree was a bad plan and it had to be one-upped. Well, *somebody* had better get their act together and talk with me about the migration document. I don't care about the ebuild so much as I do about making sure there's a howto for the migration process. If baselayout-2 OpenRC are the future of Gentoo, then gosh darnit, we need to work together. That means people in the know need to communicate with me on the draft (that I've already sent to cardoe), regardless of any who's-ebuild-are-we-using-epenis-fights. :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Josh Saddler wrote: Doug Goldstein wrote: It appears my migration plan was not good enough for Mike Frysinger [EMAIL PROTECTED] and he went ahead and wrote his own version of the OpenRC ebuild, differing from the one in the OpenRC layman repo, and committed it to the tree this weekend. Since my offer to work on the migration was not good enough for him, I'm backing out and allowing him to handle the whole migration himself since I haven't heard from him at all despite Roy (author of OpenRC) and my attempts to contact him for 2 weeks regarding a migration plan for OpenRC. All issues and comments can be directed to him. I guess working together and documenting everything before having it hit the tree was a bad plan and it had to be one-upped. Well, *somebody* had better get their act together and talk with me about the migration document. I don't care about the ebuild so much as I do about making sure there's a howto for the migration process. If baselayout-2 OpenRC are the future of Gentoo, then gosh darnit, we need to work together. That means people in the know need to communicate with me on the draft (that I've already sent to cardoe), regardless of any who's-ebuild-are-we-using-epenis-fights. :) I was trying to work together with the docs guys, the GMN peoples, the release engineering people, and our arch teams. However, Mike The Decider Frysinger does not want to work with everyone and has chosen to do his own thing. It just sucked the fun right out of the project for me and made it disinteresting in a heart beat. I had the fun of trying his ebuild out on one of my machines this morning and it happily broke my stable amd64 install. I would give you information if I was in possession of any Mike has still yet to reply to anyone's attempts to contact him. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: Doug Goldstein wrote: All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module openrc. I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. I do not want OpenRC to come as a surprise to anyone and break their system. I expect we will leave no stone unturned and go for a very smooth transition. That being said, the bug for the addition of OpenRC is #212696 [1]. The bug for the documentation is #213988 [2]. Lastly, I will be out of town March 21st through March 23rd. I will not have IRC access but I will have e-mail and Bugzilla access. https://bugs.gentoo.org/show_bug.cgi?id=212696 https://bugs.gentoo.org/show_bug.cgi?id=213988 It appears my migration plan was not good enough for Mike Frysinger [EMAIL PROTECTED] and he went ahead and wrote his own version of the OpenRC ebuild, differing from the one in the OpenRC layman repo, and committed it to the tree this weekend. Since my offer to work on the migration was not good enough for him, I'm backing out and allowing him to handle the whole migration himself since I haven't heard from him at all despite Roy (author of OpenRC) and my attempts to contact him for 2 weeks regarding a migration plan for OpenRC. All issues and comments can be directed to him. I guess working together and documenting everything before having it hit the tree was a bad plan and it had to be one-upped. not sure why you're getting pissy. but let's put some things straight shall we. - the ebuild in question was from the layman repo. i changed things of course because it didnt cover all upgrade pieces, had obvious style problems, and did some things wrongly. You mean it wasn't bash style and instead was functional POSIX shell style. And by all upgrade paths would that include adding the bad conversion of /etc/modules.autoload.d/ and removing important ewarn msgs to users? - i'd been poking openrc on my system long before this weekend. Great. And have you been working with the docs people or the arch teams and with the Gentoo/FreeBSD guys? Because some of your changes might work on your system, but not on other systems - only pinging people on irc does not constitute real effort. we have e-mail addresses too last i checked. Refresh your mail client because I did send you e-mail. And as far as I know, Roy did too. - the package is still p.masked and de-keyworded. nothing precludes you from working on it. or writing docs. or doing anything else you're talking about doing. - and no, i dont have a problem sticking masked/de-keyworded things in the tree. people test things then. -mike It's called teamwork, Mike. It also looks awful suspicious when we don't hear a peep out of you about OpenRC until 1 day before I was going to add it to the tree. What would have been so hard about sending a follow up e-mail to the thread I started about getting OpenRC in the tree saying Hey everyone, going to stick openrc- in the tree now with some changes I feel should be made. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-core] Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
On Monday 24 March 2008, Doug Goldstein wrote: Doug Goldstein wrote: All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module openrc. I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. I do not want OpenRC to come as a surprise to anyone and break their system. I expect we will leave no stone unturned and go for a very smooth transition. That being said, the bug for the addition of OpenRC is #212696 [1]. The bug for the documentation is #213988 [2]. Lastly, I will be out of town March 21st through March 23rd. I will not have IRC access but I will have e-mail and Bugzilla access. https://bugs.gentoo.org/show_bug.cgi?id=212696 https://bugs.gentoo.org/show_bug.cgi?id=213988 It appears my migration plan was not good enough for Mike Frysinger [EMAIL PROTECTED] and he went ahead and wrote his own version of the OpenRC ebuild, differing from the one in the OpenRC layman repo, and committed it to the tree this weekend. Since my offer to work on the migration was not good enough for him, I'm backing out and allowing him to handle the whole migration himself since I haven't heard from him at all despite Roy (author of OpenRC) and my attempts to contact him for 2 weeks regarding a migration plan for OpenRC. All issues and comments can be directed to him. I guess working together and documenting everything before having it hit the tree was a bad plan and it had to be one-upped. not sure why you're getting pissy. but let's put some things straight shall we. - the ebuild in question was from the layman repo. i changed things of course because it didnt cover all upgrade pieces, had obvious style problems, and did some things wrongly. - i'd been poking openrc on my system long before this weekend. - only pinging people on irc does not constitute real effort. we have e-mail addresses too last i checked. - the package is still p.masked and de-keyworded. nothing precludes you from working on it. or writing docs. or doing anything else you're talking about doing. - and no, i dont have a problem sticking masked/de-keyworded things in the tree. people test things then. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: Doug Goldstein wrote: All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module openrc. I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. I do not want OpenRC to come as a surprise to anyone and break their system. I expect we will leave no stone unturned and go for a very smooth transition. That being said, the bug for the addition of OpenRC is #212696 [1]. The bug for the documentation is #213988 [2]. Lastly, I will be out of town March 21st through March 23rd. I will not have IRC access but I will have e-mail and Bugzilla access. https://bugs.gentoo.org/show_bug.cgi?id=212696 https://bugs.gentoo.org/show_bug.cgi?id=213988 It appears my migration plan was not good enough for Mike Frysinger [EMAIL PROTECTED] and he went ahead and wrote his own version of the OpenRC ebuild, differing from the one in the OpenRC layman repo, and committed it to the tree this weekend. Since my offer to work on the migration was not good enough for him, I'm backing out and allowing him to handle the whole migration himself since I haven't heard from him at all despite Roy (author of OpenRC) and my attempts to contact him for 2 weeks regarding a migration plan for OpenRC. All issues and comments can be directed to him. I guess working together and documenting everything before having it hit the tree was a bad plan and it had to be one-upped. not sure why you're getting pissy. but let's put some things straight shall we. - the ebuild in question was from the layman repo. i changed things of course because it didnt cover all upgrade pieces, had obvious style problems, and did some things wrongly. You mean it wasn't bash style and instead was functional POSIX shell style. that wasnt what i was referring to, but converting to the tree standard only makes sense for something going into the tree. And by all upgrade paths would that include adding the bad conversion of /etc/modules.autoload.d/ looks/tested correct to me breaks for anything with a module parameter -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
On Monday 24 March 2008, Doug Goldstein wrote: Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: And by all upgrade paths would that include adding the bad conversion of /etc/modules.autoload.d/ looks/tested correct to me breaks for anything with a module parameter last i looked module parameters were not allowed. but it's a good thing it's p.masked so we can fix it easily. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: And by all upgrade paths would that include adding the bad conversion of /etc/modules.autoload.d/ looks/tested correct to me breaks for anything with a module parameter last i looked module parameters were not allowed. but it's a good thing it's p.masked so we can fix it easily. -mike /etc/modules.autoload.d has always allowed module parameters to appear after the module name. /etc/conf.d/modules has allowed a completely different syntax requiring variables based on the module name to be set with the module parameters. This is where Roy and I have been stuck as far as an automatic conversion process. The stuff you included in the openrc- ebuild was something I had sent to Roy months ago before I realized module parameters would be an issue. Looking at a swath of various /etc/modules.autoload.d/ files, I haven't come up with shell code that does the right thing everytime with all the files, which is why I've left it up to being a manual process for the user and simply documenting it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
On Monday 24 March 2008, Doug Goldstein wrote: /etc/modules.autoload.d has always allowed module parameters to appear after the module name. /etc/conf.d/modules has allowed a completely different syntax requiring variables based on the module name to be set with the module parameters. This is where Roy and I have been stuck as far as an automatic conversion process. The stuff you included in the openrc- ebuild was something I had sent to Roy months ago before I realized module parameters would be an issue. Looking at a swath of various /etc/modules.autoload.d/ files, I haven't come up with shell code that does the right thing everytime with all the files, which is why I've left it up to being a manual process for the user and simply documenting it. expecting users to read and do it themselves is certainly a path to destruction for many. while i could have written it in shell, i just did it in awk. i hope you're just overstating things when you say months, because FIXED:INCVS. we're going to need to extend the syntax anyways to allow for per-version-per-module arguments. unless openrc does that now ... Roy ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: /etc/modules.autoload.d has always allowed module parameters to appear after the module name. /etc/conf.d/modules has allowed a completely different syntax requiring variables based on the module name to be set with the module parameters. This is where Roy and I have been stuck as far as an automatic conversion process. The stuff you included in the openrc- ebuild was something I had sent to Roy months ago before I realized module parameters would be an issue. Looking at a swath of various /etc/modules.autoload.d/ files, I haven't come up with shell code that does the right thing everytime with all the files, which is why I've left it up to being a manual process for the user and simply documenting it. expecting users to read and do it themselves is certainly a path to destruction for many. while i could have written it in shell, i just did it in awk. i hope you're just overstating things when you say months, because FIXED:INCVS. we're going to need to extend the syntax anyways to allow for per-version-per-module arguments. unless openrc does that now ... Roy ? -mike Currently OpenRC does not support per-version-per-module arguments. What is your proposed syntax? -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: bzr.eclass into Portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Christian Faulhammer schrieb: | We have a prior version for some time now in the Emacs overlay for two | live ebuilds...so we go and merge your changed (ulm already did), test | it and report any problems. I just copied the bzr.eclass from the desctop-effects overlay over to my own one. And I had to find out, that bzr fails when updating an ebuild which uses the lp: address scheme[1]. So perhaps, the support for this scheme should be removed until it is fixed. Regards, Necoro [1] https://bugs.launchpad.net/bzr/+bug/181945 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6FVC4UOg/zhYFuARAkmbAJ0cFEFGeZubvjhocmgPcTFXL6hdzACfYpGE WP5z9YJri1NZzdQkHQ/Nv7E= =YWvP -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
