https://github.com/horgix/cfn-init-symlink-bugreport
:bug: Explanations and minimal example to reproduce a bug on CloudFormation, affecting the way cfn-init handles symlinks to be created
https://github.com/horgix/cfn-init-symlink-bugreport
aws bugreport cfn cloudformation symlink
Last synced: 7 months ago
JSON representation
:bug: Explanations and minimal example to reproduce a bug on CloudFormation, affecting the way cfn-init handles symlinks to be created
- Host: GitHub
- URL: https://github.com/horgix/cfn-init-symlink-bugreport
- Owner: Horgix
- Created: 2016-12-21T12:28:37.000Z (almost 9 years ago)
- Default Branch: master
- Last Pushed: 2017-04-09T17:14:47.000Z (over 8 years ago)
- Last Synced: 2025-03-05T17:46:06.850Z (7 months ago)
- Topics: aws, bugreport, cfn, cloudformation, symlink
- Homepage:
- Size: 5.86 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
This repository contains a minimum example for what looks like a bug on
cfn-init.
# The problem itself
## Context
Simply using `cfn-init` to create a symlink described in the `Metadata`
property given to an `AWS::EC2::Instance` object.
Relevant parts of the documentation, taken from
:
> content: [...] When you create a symlink, specify the symlink target as the content.
> mode: [...] Use the first three digits for symlinks and the last three digits
> for setting permissions. To create a symlink, specify 120000. To specify
> permissions for a file, use the last three digits, such as 000644.
> The following example snippet creates a symlink /tmp/myfile2.txt that points
> at an existing file /tmp/myfile1.txt.
```
files:
/tmp/myfile2.txt:
content: "/tmp/myfile1.txt"
mode: "120000"
```
From my understanding, creating a symlink to a file should not modify the
linked file.
## Stack "without mode"
Take the stack described in the `no-mode` tag of this repository, with the
following Metadata:
```
Metadata:
AWS::CloudFormation::Init:
config:
files:
"/home/ubuntu/demo_link":
content: "/etc/issue"
owner: "ubuntu"
group: "ubuntu"
```
What is **expected** is a simple file `/home/ubuntu/deno_link` with
`/etc/issue` as **content** (not a symlink in any way). Let's see how it goes.
```
$ ls -la /home/ubuntu/demo_link
-rw-r--r-- 1 ubuntu ubuntu 10 Dec 21 10:45 /home/ubuntu/demo_link
```
This is fine. Plain file with `0644` default mode, as expected.
```
$ cat /home/ubuntu/demo_link
/etc/issue
```
This is fine too. We have the file's **content** as expected.
```
$ ls -la /etc/issue
-rw-r--r-- 1 root root 26 Aug 12 17:48 /etc/issue
```
This is also fine: it's the `/etc/issue` by default of the AMI, untouched in
any way.
## Stack "with symlink mode"
Now, let's take the stack described in the `symlink-mode` tag of this
repository, with the following Metadata:
```
Metadata:
AWS::CloudFormation::Init:
config:
files:
"/home/ubuntu/demo_link":
content: "/etc/issue"
mode: "120000"
owner: "ubuntu"
group: "ubuntu"
```
Note that the difference is only this :
```
$ git diff no-mode symlink-mode
diff --git a/cf-stack.yml b/cf-stack.yml
index d962676..367bd18 100644
--- a/cf-stack.yml
+++ b/cf-stack.yml
@@ -72,5 +72,6 @@ Resources:
files:
"/home/ubuntu/demo_link":
content: "/etc/issue"
+ mode: " 120000"
owner: "ubuntu"
group: "ubuntu"
```
Let's take a look at what it produces.
```
$ ls -la /home/ubuntu/demo_link
lrwxrwxrwx 1 ubuntu ubuntu 10 Dec 21 10:55 /home/ubuntu/demo_link -> /etc/issue
```
Ok, we're fine here, it created a symlink to the good file, as expected.
```
$ ls -la /etc/issue
---------- 1 root root 26 Aug 12 17:48 /etc/issue
```
And here we go. It just set the **mode of the linked file**, `/etc/issue`, to
`0000`. If we set the mode to "120654" it will set the `/etc/issue` mode to
`0654` and so on.
# What I expected
For me, the "To create a symlink, specify 120000" should be strictly respected.
I don't expect something that create a link to a file to touch this file by any
mean : when you do a simple `ln -s TARGET LINK_NAME`, `ln` will not touch
anything on the `LINK_NAME` file since it's taken strictly as a link **name** :
it's just a property of you link, that's why you can even create symlink to
things that don't exist.
# How to reproduce it
Just run the stack defined in `cf-stack.yml` with the following parameters :
- VpcId
- KeyPair
- SubnetId
- AZ
There are 2 tags on this repository :
- `no-mode` on commit `ce10023e98d490de53ab4d8a27b7ae947b8ceb9b`
- `symlink-mode` on commit `c373c95593d7cacd9ed0568dbd4324c7a89ad1c6`
They both provide the CloudFormation stack to test yourself what I just
explained (the problem is in the `symlink-mode` one).
You'll also find what is needed to spawn this stack from Ansible if you prefer,
but this problem is absolutely not related to Ansible whatsoever and can be
reproduced by spawning this stack "by hand" on the CloudFormation web-UI.