Ok, this should be so simple. I have a large site with many folders and files. Interspersed within all of those files are files which need to be executable, so I do not want to remove those permissions. I also do not want to add executable permissions where they are not warranted.
What I do want to do is to add group write permissions to the whole site without changing other permissions. What I need is a chmod operator which 'leaves the permission as is.' So for example, if the operator which doesn't change the persmission was "~" then I could use
$chmod -R g=rw~ foldername
...and thus I would add group Write permissions across the site without changing the executable permissions.
I just can't find documentation on actual operator which functions like "~" in my above example. I thought using +,- was the trick but I must be missing something on the syntax. Thanks in advance.
Related
There's an external server that deposits some files inside a folder of my computer.
I need to automatically change the user ownership of every file created inside that folder.
I've seen a lot of answers saying that I could just change the GROUP ownership through setfacl (from my research it is not possible to change the USER ownership through setfacl).
In this case, I can't, because there's a script owned by the user A (not root) that is going to chmod this deposited file owned by the user B, and you can only chmod a file that you own.
Instead of this (inside the script):
chmod 777 /folder/file.txt
I tried this:
sudo chmod 777 /folder/file.txt
But a password is asked and BAM!
Do you have any ideas on how to deal with this?
Am I missing something?
I am not sure what you want to achieve, so here's a couple of suggestions:
if the goal is simply for the file to have specific permission settings, and ownership change is secondary, you could set the permissions correctly on the source computer and then use a transfer method that preserves permissions (scp -p or some such)
note that a script owned by A can still be run by B if A has set the permissions correctly (group and other executable bit). When B runs A's script, it runs with B's permissions, so changing permission bits of B's file will work
if ownership change is imperative, you could transfer the file to B, make sure A has permission to read (see above), and then have A make a copy of the file to A's own directory using the cp command. The copy will be owned by A and thus A can change permissions of the copy. After that, run some regular process to clean up B's directory in order to save space if that's an issue
alternatively, you could have B on the source computer log into A's account on the receiving computer, and then the file ends up in A's ownership. If you do not want to give B the password of A, you could do this using an ssh certificate. But of course this has other security risks, so the cp method above is safer
finally, on unix it is generally not a good idea to make files writable for "other", and often not even for "group", so permission settings of 775 or 755 are much safer and preferred. Otherwise anyone on the same computer could modify the file or make it an empty file. Even on a private computer this is good practice, because sooner or later one of these files will get copied to a multi-user system and no-one remembers to check the permissions
Hopefully some of these hints are useful.
One way may be to use the group sticky bit on the parent directory. This ensures that when created the files are given the same group ownership as the directory that they are in.
In most cases this is enough as you can ensure that the group is one that the file creator and the users all are members of, so they all have access to the files.
You can sticky the user ID of the directory, but this is almost always the wrong thing to do in an organisation, as it only takes that person to be away and the directory overflows.
chown owner:group directory -R
Example:
chown root:root sysadmin -R
try this.
In a script, should I create a file first and then, use CHMOD to assign permissions (Example- first using TOUCH command to create a file and then, using CHMOD to edit permissions on that file) "OR" should I mask permissions using UMASK as I create a file ? Also, please explain what are the pros and cons of choosing one over another ?
Note: This file doesn't need to be executed.
As with most things, it depends on far more information than you've given :-)
However, it's usually a good idea to do things in a closed manner then open them up, rather than the other way around. This is basic "Security 101".
For example, let's say you're creating a file for the user and the user has foolishly selected a umask of zero (effectively all files created will have full permissions for everyone).
In that case, the file is fully open for anyone to change between the creation and chmod stage and, while you can minimise this time, you cannot really remove it totally.
For the truly paranoid among us, it would be better to actually create the file in as closed a manner as possible (probably just rw for owner), do whatever you have to do to create the content of that file, then use chmod to open it up to whatever state it needs to be, something like:
( umask 177 ; create_file myfile.txt ; chmod 644 myfile.txt )
Briefly saying - it doesn't matter. And in most cases approach depends on your needing.
If you need the same file permissions over whole your script logic, I would prefer to setup it in the beginning of the script and just create file rather than create and run chmod command. However you can set file permissions at once at the end of script running chmod 0XXX -R /path/to/folder
You should always have UMASK for specific user as you don't want to be dealing with setting permissions every-time you or an application create a file. You can further protect/release any specific files if you want using CHMOD (these cases will be very rare). Unless the file you are creating needs to be protected/accessed specifically, you should have a UMASK working for it's permissions.
Create a separate user and specified directory for the application that is running the script.
set it's appropriate UMASK.
Specify extra permissions if you need it
I'd like to delete a user from a tarball that contains the files for a Linux OS (it's a tarball of the root [/] filesystem). Is there a way to do this completely and properly such that it would mimic the steps taken by the userdel command? I suppose I have two choices:
Work within the OS on an actual target, use userdel and then re-tar
the files. Not a problem, but I was curious about acting directly
on the tarball, hence...
I could mimic the steps taken by userdel: un-tar and delete all entries related to the user...according to the man
page of userdel I would delete entries in /etc/group,
/etc/login.defs, /etc/passwd, and /etc/shadow. Then, re-tar.
Approach (2) is attractive because I could programmatically add or delete users directly on the tarball. I'll try (2), but wondering if there would be any unintended consequences or leftover bookkeeping that I should do? Or is there another way to do this?
/etc/login.defs is only called when a new user is created. That file does not need to be modified. However, a mail spool will be created for the user in the location listed in login.defs
Deleting the user from /etc/shadow and /etc/passwd will work. /etc/group is not a requirement however it cant hurt. Those three files will take care of it, You may delete the mail spool if desired.
I have a folder that I own, but also has read permissions for the entire group. I would like to know who read/copied the contents and when. Is it possible to do this with a script or otherwise?
kernel’s audit system can be used for this
Is it possible to setup directory permissions such that a group is able to read and write files and subdirectories but not delete anything?
It might be enough to set the sticky bit on the directories. Users will be able to delete any files they own, but not those of other users. This may be enough for your use case. On most systems, /tmp is setup this way (/tmp is set 1777)
chmod 1775 /controlled
However, If you want more control, you'll have to enable ACL on the filesystem in question.
In /etc/fstab, append acl to the flags:
/dev/root / ext3 defaults,acl 1 1
You can then use setfacl/getfacl to control and view acl level permissions.
Example: (Create files, once written, they are read only, but CAN be deleted by owner, but not others.)
setfacl --set u::rwxs,g::rwx /controlled
setfacl -d --set u::r-x,g::r-x,o::- /controlled
You can set a default acl list on a directory that will be used by all files created there.
As others have noted, be careful to specify exactly what you want. You say "write" - but can users overwrite their own files? Can they change existing content, or just append? Once written, it's read only? Perhaps you can specify more detail in the comments.
Lastly, selinux and grsecurity provide even more control, but that's a whole other can of worms. It can be quite involved to setup.
Well, it would be r-x for this directory.
And files in it would have rw-.
This is because a file can be written if its permissions allow Write, but it can only be deleted if its directory's permissions allow Write.
Possible or not, make sure that overwriting with a 0-byte file isn't equivalent to deleting the file in your particular context.