Re: Should rpm call umask(2)?
On Jul 27, 2007, at 4:44 PM, Michael Jennings wrote: On Wednesday, 11 July 2007, at 11:40:15 (+0200), Michael Schroeder wrote: Uh, not 002 please, 022 is the standard. Make it configurable if you really need to do something like that. Wouldn't this prevent the creation of group-writable files and directories? Group write permissions *are* useful in many circumstances Yes. And yes. But 0022 is the default setting, certainly choosing the uglix standard default is the least surprising choice that meets the largest number of expectations. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Friday, 27 July 2007, at 16:46:43 (-0400), Jeff Johnson wrote: But 0022 is the default setting, certainly choosing the uglix standard default is the least surprising choice that meets the largest number of expectations. On systems that use UPG, 0002 is the default. And last time I used AIX, was the default. It just seems to me that the permissions in the RPM should be honored exactly 100% as they're stored, even if that means world write permissions (such as in 1777 directories like /tmp). Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I've been looking for a Savior in these dirty streets, Looking for a Savior beneath these dirty sheets. -- Tori Amos, Crucify __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Jul 27, 2007, at 7:20 PM, Michael Jennings wrote:
On Friday, 27 July 2007, at 16:46:43 (-0400),
Jeff Johnson wrote:
But 0022 is the default setting, certainly choosing the uglix
standard default is the least surprising choice that meets the
largest number of expectations.
On systems that use UPG, 0002 is the default. And last time I used
AIX, was the default.
It just seems to me that the permissions in the RPM should be honored
exactly 100% as they're stored, even if that means world write
permissions (such as in 1777 directories like /tmp).
I will add the macro, and postpone setting until end, not beginning,
of macro loads.
Truly, bootstrapping the dumpty-humpty rpm through external, maximally
flexible,
macros with embedded %{_target_platform} in path, with run-time
zeroconf discovery
of configuration, is getting way too complex again again.
At least rpmrc (and RPMTAG_ARCH) are finally Dead! Dead! Dead!
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Tue, Jul 10, 2007 at 03:14:11PM -0400, Jeff Johnson wrote:
This ancient bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83006
keeps resurfacing.
It's trivial to add to main()
mode_t mask = 002;
Uh, not 002 please, 022 is the standard. Make it configurable if you
really need to do something like that.
And while you're at it, don't forget to reset the environment and the
process limits (setrlimit). ;-)
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Jul 11, 2007, at 5:40 AM, Michael Schroeder wrote: On Tue, Jul 10, 2007 at 03:14:11PM -0400, Jeff Johnson wrote: This ancient bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83006 keeps resurfacing. It's trivial to add to main() mode_t mask = 002; Uh, not 002 please, 022 is the standard. Make it configurable if you really need to do something like that. I appear to have not yet checked in the change to lib/rpmrc.c. And while you're at it, don't forget to reset the environment and the process limits (setrlimit). ;-) The RHEL4 rpm resets the side effects of LD_ASSUME_KERNEL=x.y.z perfectly. Be very careful what you ask for, lest you have to support it. Sickest patch I ever professionally applied. Ever. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Jul 11, 2007, at 7:00 AM, Ralf S. Engelschall wrote: On Wed, Jul 11, 2007, Michael Schroeder wrote: On Tue, Jul 10, 2007 at 03:14:11PM -0400, Jeff Johnson wrote: It's trivial to add to main() mode_t mask = 002; Uh, not 002 please, 022 is the standard. Make it configurable if you really need to do something like that. [...] Yes, good point: please use 022 as the default and allow it to be overriden with a macro, Jeff. umask can be set as a side effect of any macro expansion, lua coding exercise left to the advanced user. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Wednesday 11 July 2007 09:07, Jeff Johnson [EMAIL PROTECTED] wrote: The sys-admin should be able to run rpm and have the packages either correctly installed or the installation should abort. There should be no other possible result. Even if the disk isn't spinning or is going click ... click ... click? If the hardware fails then the RPM database files that indicate the status of the packages should not report the new version as successfully installed. I suspect that the installation is permitted to hang in unfinished system calls at elevated irq levels too ;-) The system may hang, but may not report success when that did not happen. umask(2) change committed, fsync(2) yesterday as well. Great! -- [EMAIL PROTECTED] http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Should rpm call umask(2)?
This ancient bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83006 keeps resurfacing. It's trivial to add to main() mode_t mask = 002; (void) umask(mask) and ignore the umask issue forevermore. The trickier problem is that once rpm starts to manage its own environment, with envvar's and umask and whatever else, then the environment must be propagated and continued and configured and adjusted and ... forevermore. So, simple expedient hack or better asbestos for my flak suit? 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Tue, Jul 10, 2007, Arkadiusz Miskiewicz wrote: On Tuesday 10 of July 2007, Ralf S. Engelschall wrote: On Tue, Jul 10, 2007, Mark Hatle wrote: For something to software installs, I think it's reasonable to set the default umask instead of using the environment's. Yes, also my opinion. RPM is an installer and one expects more that it operates on its stuff totally independent from the calling environment. Setting at least umask in main() is reasonable IMHO. I agree. Unfortunately Jeff once disagreed about things like this. For example %post/%pre etc scripts are not run in clean stable enviroment - calling env is used instead. Yes, that's the approach we use in OpenPKG, too. We actually use this approach of a sane environment for all % scripts, including and most notably %build and %install. Without this we many years ago we resulted in many nice errors from users with umasks settings of 077 and similar ;-) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Jul 10, 2007, at 3:48 PM, Ralf S. Engelschall wrote: On Tue, Jul 10, 2007, Arkadiusz Miskiewicz wrote: On Tuesday 10 of July 2007, Ralf S. Engelschall wrote: On Tue, Jul 10, 2007, Mark Hatle wrote: For something to software installs, I think it's reasonable to set the default umask instead of using the environment's. Yes, also my opinion. RPM is an installer and one expects more that it operates on its stuff totally independent from the calling environment. Setting at least umask in main() is reasonable IMHO. I agree. Unfortunately Jeff once disagreed about things like this. For example %post/%pre etc scripts are not run in clean stable enviroment - calling env is used instead. Yes, that's the approach we use in OpenPKG, too. We actually use this approach of a sane environment for all % scripts, including and most notably %build and %install. Without this we many years ago we resulted in many nice errors from users with umasks settings of 077 and similar ;-) The ayes (and lusers) have it. I'll whack a sane umask call into main this evening. My issue(s) are 1) the workaround, setting umask before invoking rpm, is entirely feasible. 2) I want to see remote scriptlet execution some day, and I don't want to carry a umask (or any envvar) setting around. But the same 2 lines on the remote scriptlet server will work just fine. BTW, is there any reasonable rcmd(3)-like ssh library around? I've looked at the OpenBSD thingy but it made my head hurt. 73 de Jeff Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Wednesday 11 July 2007 05:26, Jeff Johnson [EMAIL PROTECTED] wrote: But +1 for the 2 line hack noted. Another +1. The sys-admin should be able to run rpm and have the packages either correctly installed or the installation should abort. There should be no other possible result. -- [EMAIL PROTECTED] http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Should rpm call umask(2)?
On Jul 10, 2007, at 6:55 PM, Russell Coker wrote: On Wednesday 11 July 2007 05:26, Jeff Johnson [EMAIL PROTECTED] wrote: But +1 for the 2 line hack noted. Another +1. The sys-admin should be able to run rpm and have the packages either correctly installed or the installation should abort. There should be no other possible result. Even if the disk isn't spinning or is going click ... click ... click? I suspect that the installation is permitted to hang in unfinished system calls at elevated irq levels too ;-) umask(2) change committed, fsync(2) yesterday as well. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
