Symlinks (CHEF 2749 2389 2747)


#1

Hi there,

could you to tell us what you think about these 3 non-fixed
non-acknowledged tickets please ?

what kind of fixes would you accept ?


#2

On Nov 28, 2011, at 6:42 AM, laurent+opscode@u-picardie.fr wrote:

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.

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.

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.

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.

what kind of fixes would you accept ?

For #1, I’m not seeing that anything in Chef is broken. For #2, I think the provider should be fleshed out, but in the meanwhile maybe Chef could be more explicit in bombing out with an appropriately descriptive error. For #3, I need to understand the problem better.


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#3

Hi Brad,
Thanks for you answers.

I tend to complicate things a bit. so i’ll try to answer with short
simple sentences :slight_smile:

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.

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.

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.

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.


Laurent


#4

On Mon, Nov 28, 2011 at 8:13 AM, laurent+opscode@u-picardie.fr wrote:

Hi Brad,
Thanks for you answers.

I tend to complicate things a bit. so i’ll try to answer with short
simple sentences :slight_smile:

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.

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.

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 :slight_smile:

Matthew Kent | http://magoazul.com