Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

file.line with mode=delete does not preserve ownership of a file #38452

Closed
jf opened this issue Dec 27, 2016 · 6 comments
Closed

file.line with mode=delete does not preserve ownership of a file #38452

jf opened this issue Dec 27, 2016 · 6 comments
Labels
Bug broken, incorrect, or confusing behavior Execution-Module P1 Priority 1 Platform Relates to OS, containers, platform-based utilities like FS, system based apps severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Milestone

Comments

@jf
Copy link
Contributor

jf commented Dec 27, 2016

Description of Issue/Question

If you use file.line with mode: delete, if a successful deletion occurs, the ownership of the file is not preserved (but changes to root:root)

Steps to Reproduce Issue

Use file.line with mode: delete in a state file, and set it up to successfully delete at least one line in a file on the minion that is not owned by root. After the state has run, you will see that the file is now chowned root:root.

Versions Report

2016.11.1 on both master and minion.

@gtmanfred gtmanfred added Bug broken, incorrect, or confusing behavior Execution-Module severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around P1 Priority 1 Platform Relates to OS, containers, platform-based utilities like FS, system based apps TEAM Platform labels Dec 29, 2016
@gtmanfred gtmanfred added this to the Approved milestone Dec 29, 2016
@gtmanfred
Copy link
Contributor

Thanks for reporting this.

I have confirmed the problem, and it looks like we just don't maintain the ownership in the file.line execution function.

I have tagged this as a bug for our platform team to take a look.

Thanks,
Daniel

@gtmanfred
Copy link
Contributor

Can you verify if this is fixed in 2016.11.4?

Thanks,
Daniel

@hatifnatt
Copy link

No it's still not fixed. file.line still change ownership to root:root
Debian 7
dpkg -l "salt*"

ii  salt-common      2016.11.5+ds
ii  salt-master      2016.11.5+ds
ii  salt-minion      2016.11.5+ds
ii  salt-syndic      2016.11.5+ds

@gtmanfred
Copy link
Contributor

Are you using the file.line execution module, or the state module?

This should work in a state now, after this #39592

@hatifnatt
Copy link

I'm using state module. There is the code:

create_file:
  file.managed:
    - name: /tmp/38452.tmp
    - source: salt://{{ slspath }}/38452.tmp
    - user: hatifnatt
    - group: hatifnatt
    - mode: 644
    - skip_verify: True
    - require_in:
      - file: delete_line

delete_line:
  file.line:
    - name: /tmp/38452.tmp
    - mode: delete
    - content: "22222"

38452.tmp

11111
22222
33333

Run it:
salt 'vds01*' state.sls issue.38452

          ID: create_file
    Function: file.managed
        Name: /tmp/38452.tmp
      Result: True
     Comment: File /tmp/38452.tmp updated
     Started: 19:04:47.749496
    Duration: 812.315 ms
     Changes:
              ----------
              diff:
                  ---
                  +++
                  @@ -1,3 +1,3 @@
                   11111
                  -44444
                  +22222
                   33333
              group:
                  hatifnatt
              user:
                  hatifnatt
----------
          ID: delete_line
    Function: file.line
        Name: /tmp/38452.tmp
      Result: True
     Comment: Changes were made
     Started: 19:04:48.562007
    Duration: 29.581 ms
     Changes:
              ----------
              diff:
                  ---
                  +++
                  @@ -1,4 +1,3 @@
                   11111-22222 33333

After execution:

ls -la /tmp/38452.tmp
-rw-r--r-- 1 root root 12 Июл 10 19:04 /tmp/38452.tmp

cat /tmp/38452.tmp
11111
33333

@gtmanfred
Copy link
Contributor

Nevermind, it does look like the first time this is run, it still changes the user back to the user and group that salt-minion is running as. On the second run, After the line is deleted, the user does get changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior Execution-Module P1 Priority 1 Platform Relates to OS, containers, platform-based utilities like FS, system based apps severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Projects
None yet
Development

No branches or pull requests

3 participants