[chef-dev] Re: Re: symlinks (CHEF 2749 2389 2747)

[Matthew Kent < >]

On Mon, Nov 28, 2011 at 8:13 AM,  
<
 >
 wrote:
>
> Hi Brad,
> Thanks for you answers.
>
> I tend to complicate things a bit. so i'll try to answer with short
> simple sentences :)
>
>>> - http://tickets.opscode.com/browse/CHEF-2749
>>
>> Speaking only for myself, a symlink cannot have ownership and permissions 
>> of its own.  That's why it's shown as mode 777 in both of the "before" and 
>> "after" blocks.  So, this is a non-issue.  POSIX file semantics may be 
>> tripping you up, but that's not a problem with Chef.

Symlinks on linux at least have an owner/group (see chown -h)

>>
>> Perhaps Chef could be more explicit about testing for symlinks and bombing 
>> out if you try to apply operations to them which should be applied only to 
>> regular files or directories, but I think the better solution is that you 
>> should write your cookbooks and recipes in such a way that this does not 
>> become a problem.
>
> since it's not checking for symlinks, cookbook_file can overwrite
> files outside of its scope.
> if there were less checks this would be a major security issue. (for
> instance if chef was using md5sum or no sum check at all)
>
> I guess a cookbook_file_that_also_deals_with_symlinks definition could
> be a local workaround.
>

Yikes, this could cause someone some pain.

+1 here for treating symlinks like normal files and doing the following:

1) specific log output indicating it's a symlink
2) backing up the symlink
3) removing it
4) replacing it with the cookbook file

Couldn't see anything worse here than the normal behavior of
cookbook_file in replacing data.

>>> - http://tickets.opscode.com/browse/CHEF-2389
>>
>> It's hard for a program to know what path should be applied to a command 
>> used with a relative path, unless you introduce the concept of an explicit 
>> current working directory.  Otherwise, what you think is your current 
>> working directory may in fact not match at all, and therefore the 
>> behaviour of the program could be very unexpected.
>>
>> So, I agree with your comment that this needs some fleshing out in the 
>> provider.
>
> ok.
>

Allowing for setting a cwd (default to nil) for relative symlinks
seems reasonable to me - I think this would be useful.

>>> - http://tickets.opscode.com/browse/CHEF-2747
>>
>> I've gone over this one a couple of times and I'm still not quite 
>> understanding what the problem is or what should be done about it.  But 
>> maybe that's just me and I haven't have enough coffee yet this morning.
>
> to make it short: you can't have a symlink in a remote_directory.
>
> it seems remote_directory doesn't know how to deal with symlinks at
> all.
> And anyway knife just dereferences them while uploading the cookbook.
>

To me this should work - guess no one has tried it before!

Some great stuff to implement here for sure. Nice work :)
-- 
Matthew Kent | http://magoazul.com