List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:December 11 2008 3:48pm
Subject:Re: [Fwd: Bug 32398]
View as plain text  
I think it could be made to work using a second account, the restricted 
deletion bit (aka the sticky bit), and a minor piece of magic to change 
back the file owner, but at best would make it inconvenient, not 
impossible, to delete table spaces.

Now, on VMS, there was an explicit privilege for that sort of 
non-sense.  It was sometime asked what the point of prevent a user who 
could truncate a file to nothingness from deleting the file, and what 
was the point of having a file that someone could write but not read.

Now, as for VMS, I still have a product being peddled there (HP's 
Datatrieve on the Itanic), but I wasn't foolish enough to give them an 
open ended consulting contract.  Among my profession principles are:

    17.  I don't program 16 bit computers
    47.  I don't do VMS even if renamed OpenVMS

Sorry, if you want to do VMS, you're on your own.

Vladislav Vaintroub wrote:
> Changing file attributes seems  too sneaky for me:) 
> removing write on parent directory is bad, as it makes creating file in the
> directory impossible. Playing with file attributes requires specific file
> systems (except on Windows) and does not have documented apis (again except
> on Windows)
>
> So I'd say, for the purpose of the bug fix, adding ".fts" extension if it is
> not  already there does not sound too bad. And, the file systems I know of,
> can all swallow 
> multiple dots in the file name (on VMS it could not be the case, but we do
> not port to VMS in the next century I hope;)
>
>
>   
>> -----Original Message-----
>> From: Sergey.Vojtovich@stripped [mailto:Sergey.Vojtovich@stripped] On
>> Behalf Of Sergey Vojtovich
>> Sent: Thursday, December 11, 2008 2:33 PM
>> To: Jim Starkey
>> Cc: Ann W. Harrison; Vladislav Vaintroub; 'Kevin Lewis';
>> falcon@stripped
>> Subject: Re: [Fwd: Bug 32398]
>>
>> Hi Jim,
>>
>> it would pretty nice to create files without delete permission, but how
>> is
>> it achievable? E.g. on linux/ext2 there're two options: unset parent
>> directory write access or use chattr +a. Both seem to be something
>> that we can't use.
>>
>> Anyway... any decision on this issue? Does anybody want to say the
>> final
>> word? :)
>>
>> Regards,
>> Sergey
>>
>> On Sat, Nov 29, 2008 at 04:30:04PM -0500, Jim Starkey wrote:
>>     
>>> Ann W. Harrison wrote:
>>>       
>>>> Kevin wrote:
>>>>
>>>>         
>>>>>>> I am in favor of adding .fts automatically to tablespace
> file
>>>>>>>               
>> names
>>     
>>>>>>> that have no extension, and it seems that so is Ann.
>>>>>>>               
>>>> Actually, I'm in favor of adding .fts to all tablespace file names
>>>> that don't already end in .fts.  So tablespace.awh would become
>>>> tablespace.awh.fts, and tablespace.MYI would become
>>>>         
>> tablespace.MYI.fts.
>>     
>>>> What I don't know is whether there are any supported operating
>>>>         
>> systems
>>     
>>>> that are strict about the number of extensions on a file.  DOS did,
>>>> and so did VAX/VMS, but those are both ancient history, saints be
>>>> praised!
>>>>
>>>> Vlad wrote:
>>>>
>>>>         
>>>>> The thing with the bug is that so far there is nothing falcon that
>>>>>           
>> would
>>     
>>>>> prevent creating  tablespace named t1.MYI or t1.par or whatever
>>>>> extensions
>>>>> server is using for different purposes.
>>>>>           
>>>> Maybe we could prevail on the server not to delete pre-existing
>>>>         
>> files
>>     
>>>> when creating tables and partitions.  We don't delete pre-existing
>>>> files when creating tablespaces ...
>>>>         
>>> Maybe we should get sneaky and create all Falcon files without delete
>>> permission, turning delete back on when we are good and ready to
>>>       
>> delete
>>     
>>> files.  Any reasonably privileged user could do the same thing, but
>>>       
>> he'd
>>     
>>> have to think twice about what he was doing.  But it will protect
>>>       
>> Falcon
>>     
>>> users from the server unless the server picks up the same trick.
>>>
>>>
>>> --
>>> Jim Starkey
>>> President, NimbusDB, Inc.
>>> 978 526-1376
>>>
>>>       
>> --
>> Sergey Vojtovich <svoj@stripped>
>> MySQL AB, Software Engineer
>> Izhevsk, Russia, www.mysql.com
>>     
>
>
>   


-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376

Thread
Re: [Fwd: Bug 32398]Jim Starkey29 Nov
Re: [Fwd: Bug 32398]Kevin Lewis11 Dec
RE: [Fwd: Bug 32398]Vladislav Vaintroub11 Dec
  • Re: [Fwd: Bug 32398]Jim Starkey11 Dec