0

I've tried a LOT of stuff with chmod and chown, and combinations thereof.

I still want the files in the home directory of this user to be readable to the user, just not writable or executable. However I still want the home folder of the user to be writable by that user, so the user can add files to the folder but not delete the ones inside the folder that have had these commands run on them.

More data:

  1. this home directory is encrypted
  2. I don't really care if the solution I'm asking for is multiple lines, as long as I can put it in a bash script
  • 3
    What is your motivation? Is it to stop annoying “I just deleted that useful file” complaints? Is it a [misguided] attempt at security? Is it something else? – ctrl-alt-delor Dec 23 '18 at 19:25
2

The only way I know to do what you are asking for is with chattr(1) which as name suggest change files attributes.

Under attributes section you can read:

"A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute."

--practical case:

: lsattr example.file
------------------- example.file
: ls -lh example.file 
-rw------- 1 tntx tntx 15 Dec 23 20:43 example.file
: su -
Password:
root@foo: chattr +i example.file
root@foo: exit
logout
: lsattr example.file 
----i-------------- example.file
: cat example.file 
testing chattr
: echo "adding text" >> example.file 
ksh93: example.file: cannot create [Operation not permitted]

Same with vi:
Read-only file, not written; use ! to override.
:w!
Error: example.file: Operation not permitted.

And then trying to mv:
: mv example.file example.file2 
mv: cannot move 'example.file' to 'example.file2': Operation not permitted

What about cp:
: ls -lh example.file*
-rw------- 1 tntx tntx 15 Dec 23 20:43 example.file
-rw------- 1 tntx tntx 15 Dec 23 21:02 example.file2
: /usr/bin/lsattr example.file*
----i-------------- example.file
------------------- example.file2

So it fails because you can lock the file to be only readable by user but will be free to cp(1) and edit in new file.

  • I was about to tell it would work only on ext2/3/4, but it's also available for xfs and btrfs covering many common cases even if probably not all. No idea about a possible encryption interaction from OP's question. – A.B Dec 23 '18 at 20:47
0

chmod is not enough, as user can just change the mode.

First stop the user from editing the file:

  • chmod go-w «the-file-name»
  • chown «some-other-user» «the-file-name»

Now the user could still delete the file, so let us stop that. (a file is deleted, if it is removed from the containing directory. We need to stop that.)

  • chown «some-other-user» «the-containing-directory»
  • chmod +t «the-containing-directory»

Now make it so the user can write to the containing-directory

  • chown «the-users-name» «the-containing-directory»
  • chmod g+w «the-containing-directory»

There is nothing you can to to stop execution. You can not set the execute bit, but if the user can read the file, then they can copy it. If they can copy it, then they can make it executable.

  • @A.B noexec can be got around for scripts (bash, python, java). Just launch the interpreter manually. – ctrl-alt-delor Dec 23 '18 at 19:37
  • I might be wrong, but the user would still be able to move the containing directory. If it is a concern, bind mounting the containing directory to itself should prevent this. – fra-san Dec 23 '18 at 19:49
  • @ctrl-alt-delor yes I realized this and deleted my comment, but I was too slow – A.B Dec 23 '18 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.