rebase db perms seem too restrictive

Shaddy Baddah
Tue Nov 18 01:58:00 GMT 2014


On 17/11/14 20:26, Corinna Vinschen wrote:
> On Nov 17 14:14, Shaddy Baddah wrote:
>> Hi,
>> I expect that there wasn't any explicit reasoning behind this, but
>> rebase creates a db with permissions that are too restrictive. To me
>> anyway, as I cannot see any danger in the db being readable by all.
>> This snippet describes it:
>> <snip>
>> $ whoami
>> sbaddah
>> $ od -c /etc/rebase.db.x86_64
>> od: /etc/rebase.db.x86_64: Permission denied
>> $ ls -l /etc/rebase.db.x86_64
>> -rw-rw---- 1 portapps None 86020 Nov 11 15:34 /etc/rebase.db.x86_64
>> </snip>
>> I've attached an untested patch that would allow at least world readable
>> perms. It would be appreciated if it was applied :-)
>> --
>> Regards,
>> Shaddy
>> diff --git a/rebase.c b/rebase.c
>> index 9504a48..a078e1d 100644
>> --- a/rebase.c
>> +++ b/rebase.c
>> @@ -288,7 +288,7 @@ mkstemp (char *name)
>>   {
>>     return _open (mktemp (name),
>> -      _S_IREAD|_S_IWRITE);
>>   }
>>   #endif
> That won't work.  Check the surroundng #ifdef's.  The mkstemp
> replacement function is only called when building rebase for Mingw.  If
> it's called on Cygwin, it uses Cygwin's implementation of mkstemp,
> which follows the (security) lead of other POSIX systems and creates
> the files with 0600 permissions.  After the file got written, the
> permissions are changed, see lines 358ff.

Sorry, yes I missed that. In any case, I withdraw the patch.

The initial trigger for my request was that the
/usr/lib/perl5/5.14/ExtUtils/ distributed with perl causes a
cpan/MakeMaker installation to run rebase -s against a built shared

Now I use Perl/cpan local::lib
That means my modules get built under my user, which is distinct from
the "software administrator" user (portapps), who owns the db file.

So initially, the rebase command was failing on the rebase on read
perms. However, even with that corrected, rebase -s will want to update
the db, which requires write perms.

The db file location isn't really configurable, and even if it was,
imagining an optimal setup for an installation with the potential for
multiple users building and running their own shared libraries is a
complex mess. There is no perfect world with rebase.

To that end, it is better that the db file is just writeable by the
"software administrator" so that "rebase" services are only sorted out
for the actual Cygwin install. Users would then be required to go it
alone if they need to rebase their built executables/shared libs.

And in any case, subsequent modules no longer include
rebase. Suggesting to me that someone's perhaps come to the same
conclusion. If you build your own stuff, you sort out rebasing.


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list