For example, root touch a new file under a common user's(name it bob) home directory:
/home/bob $ ls -alh a.txt
-rw-r--r-- 1 root root 0 Jul 16 17:45 a.txt
Now user bob open it with vim, and it should be readonly.
I tried to force overwrite it with :w!, and it was saved and the owner:group changed to bob:
/home/bob $ ls -alh a.txt
-rw-r--r-- 1 bob bob 4 Jul 16 17:47 a.txt
IMO, I think it can't be saved with permission denied, but it could, and the owner:group also changed.
And this can only under bob's home directory, if under outer directory, such as /tmp or others, it can't be written as I thought.
Can anyone explain this? what processes does :w! actual do? thx.
The file is readable by Bob, so Bob can open it in Vim.
The directory is writable by Bob, so Bob will be able to unlink (remove) any file therein, and write any new file to it. This is what happens when you use :w!.
This is not true for the /tmp directory, because it probably has the "sticky" bit set.
From the OS X sticky(8) manual:
A directory whose 'sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files
is restricted. A file in a sticky directory may only be removed or
renamed by a user if the user has write permission for the directory
and the user is the owner of the file, the owner of the directory, or
the super-user. This feature is usefully applied to directories such
as /tmp which must be publicly writable but should deny users the
license to arbitrarily delete or rename each others' files.
Related
I have some problem with linux "tar" command.I want to unzip a config001.gz to a directory(with owner root ,group root and 777 permission as show in pic).
My origin dir and target dir is shown in pic.
My question is:
why there is en empty folder in a config001.gz file(I try to tar two file together and look in the the config002.tgz file ,there is no empty dir)?
if I don't append --no-overwrite-dir after command,it will raise error, what permission does "tar" want to change?
why --no-overwrite-dir option can fix the problem
my mount infomation:
fuse.mfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other 0 0
why there is en empty folder in a config001.tgz file?
There is the "root folder" included in the tar archive. The folder the tar was in. The privileges, owner and group, permissions and creation/modification (or one of them, I am not sure) dates are included. You can create such archive with:
mkdir -p /tmp/a
cd /tmp/a
echo 123 > 1
echo 234 > 2
tar cfvp /tmp/test.tar .
# and inspect with:
tar -tvf ./test.tar
drwxr-xr-x kamil/kamil 0 2019-07-15 12:50 ./
-rw-r--r-- kamil/kamil 4 2019-07-15 12:50 ./2
-rw-r--r-- kamil/kamil 4 2019-07-15 12:50 ./1
By specifing the ., ie. the current directory, the information about the current directory itself will be included in he tar. Ie. the information about the owner and group, permissions and dates.
if I don't append --no-overwrite-dir after command,it will raise error, what permission does "tar" want to change?
tar wants to change the permissions of the directory you are inside. The hpc_dir directory. The hpc_dir is owned by root, so tar can't change/touch it.
why --no-overwrite-dir option can fix the problem?
Because then tar sees the the currect directory hpc_dir exists. Because of that, tar doesn't try to create the directory, nor tries to change the owner and group permissions of the directory, nor tries to restore the creation date of the directory.
You could just go with mkdir somedir; tar xzfv archive.tar -C somedir - that way the somedir will be created by current user, so tar will be able to change it's properties.
Or you could just change the owner of hpc_dir directory, letting your user modify it.
How can I prevent changing the ownership of a file?
I have a file with permission as follows:
-rw-r-----. 1 netcool ncoadmin 1689 May 8 14:54 NCI_Constellation.proj
As part of RPM package installation, I am running a script which is supposed to write data into NCI_Constellation.proj file. Whereas the permission of the file is getting changed as follows during package installation and the writing to the file is not happening.
-rw-r-----. 1 root root 1689 May 8 14:54 NCI_Constellation.proj
Is there a way to not change the ownership of NCI_Constellation.proj file and keep it as it is as follows so that I will be able to write data to the file?
-rw-r-----. 1 netcool ncoadmin 1689 May 8 14:54 NCI_Constellation.proj
Please help.
The question is: what package does that file belong to and with what permissions?
rpm -qf /path/to/NCI_Constellation.proj
will give you the package owning this file (let's say NCI.rpm). Then
rpm -qlv NCI.rpm | grep NCI_Constellation.proj
will give you the owners and rights of this file as packaged by NCI.rpm. If you are the one packaging NCI.rpm; you should put something like this in your %files section:
%files
%attr(640,netcool,ncoadmin) /path/to/NCI_Constellation.proj
By the way make sure that you really can write to the file with those permissions; test that first... Who is running the script to change this file? As which user? then run it yourself manually as that user to make sure these file permissions will suffice.
you have two options in my opinion,
first : set netcool to root group by doing this:
$ sudo usermod -a -G root netcool
with this command you user is able to change and modify the file even after the permissions changed.
second : set netcool user a second root user by changing /etc/passwd file.
for this open the file with every file-editor you want then change UID and GID to 0. after doing this if you run $ grep netcool /etc/passwd you should see :
netcool:x:0:0: {the rest may change for anybody}.
We can prevent the changing of group of file by using setgid bit on directory. So if you add user netcool to ncoadmin and give write permission to ncoadmin then you can edit the file. Here is how you can set the SetGid bit on directory.
chmod g+s your_directory_containing_file(NCI_Constellation.proj)
Bit more about the setgid on directory:
setgid can be used on directories to make sure that all files inside the directory are owned
by the group owner of the directory. The setgid bit is displayed at the same location as the x
permission for group owner. The setgid bit is represented by an s (meaning x is also there)
or a S (when there is no x for the group owner). As this example shows, even though root
does not belong to the group proj55, the files created by root in /project55 will belong to
proj55 since the setgid is set.
root#RHELv4u4:~# groupadd proj55
root#RHELv4u4:~# chown root:proj55 /project55/
root#RHELv4u4:~# chmod 2775 /project55/
root#RHELv4u4:~# touch /project55/fromroot.txt
root#RHELv4u4:~# ls -ld /project55/
drwxrwsr-x 2 root proj55 4096 Feb 7 17:45 /project55/
root#RHELv4u4:~# ls -l /project55/
total 4
-rw-r--r-- 1 root proj55 0 Feb 7 17:45 fromroot.txt
I have some file and can't delete it.
File created my user www-data:
-rw-rw-r-- 1 www-data www-data 17408 Jun 3 16:18 0.48257900 1464959885_555.png
I am trying to delete it by user lifesim:
rm -rf *
rm: cannot remove '0.48257900 1464959885_555.png': Permission denied
Why I can't delete that file?
lifesim#srvJH:~/public_html/upload/blog/posts/2016-06-03$ whoami
lifesim
lifesim#srvJH:~/public_html/upload/blog/posts/2016-06-03$ id lifesim
uid=1001(lifesim) gid=33(www-data) groups=33(www-data)
lifesim#srvJH:~/public_html/upload/blog/posts/2016-06-03$ id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(lifesim)
File created by my PHP script.
Lars Fischer is right: you need to have write permission to delete a file from a directory.
As clarified in the comments below the question: your lifesim user has no rights to change the directory containing the file.
Give lifsim or the group "w" permissions on the diretory or use the www-data user for the deletion.
Deleting (or creating) a file means we modify the directory (imagine the directory is just a database document with the file metadata) and remove (or add) the metadata of the file. Thus we must be able to change the directory.
I would like to set up a linux share space in the following way:
I want one user lets call admin to have access to all other users home directories.
I want to be able to create users A,B,C,D,E and have none of them view any other folders except there home folder(and /tmp/ if needed).
I do not want them to be able to view any other files.
I will use this so I can create a user for them they can log in view/edit a file in their home folder and nothing else(or scp a file into it)
How do I do this?
My first thought was to create a group and put them all in that group but I do not want them to be able to view each other’s files.
I notice that the folders in /home/* are only read,write,execute by the owner:
[test2#XXX home]$ pwd
/home
[test2#XXX home]$ ll
drwx------ 3 test2 test2 4096 Mar 7 18:54 test2
Is this sufficient permissions then?
The files in /home/A/ for example are
[test2#XXX~]$ pwd
/home/test2
[test2#XXX~]$ ll
total 4
drwxrwxr-x 2 test2 test2 4096 Mar 7 18:54 testdir
-rw-rw-r-- 1 test2 test2 0 Mar 7 18:54 testfile
User B would not be able to write to these files correct?
If so what do I need to do in order to have user admin able to view all these /home/ folders but nobody else.
First of all you need a user "Admin" who will have rwx permissions on all home directories of users A, B, C, D, E. Here I am assuming that your "Admin" user is not root.
You can refer to this link for achieving this functionality.
Now you don't want any of the user A, B, C, D, E to see each others' files, but a Public folder exists in your Home directory (/home/user) for sharing files with other users. If an other user wants to get access to this Public folder, the execute bit for the world should be set on the Home directory.
If you do not need to allow others to access your home folder (other humans or users like www-data for a webserver), you'll be fine with chmod o-rwx "$HOME" (remove read/write/execute from "other", equivalent to chmod 750 "$HOME" since the default permission is 750). Otherwise, you should change the umask setting too to prevent newly created files from getting read permissions for the world by default.
For a system-wide configuration, edit /etc/profile; per-user settings can be configured in ~/.profile. I prefer the same policy for all users, so I'd edit the /etc/profile file and append the line:
umask 027
You need to re-login to apply these changes, unless you're in a shell. In that case, you can run umask 027 in the shell.
Now to fix the existing permissions, you need to remove the read/write/execute permissions from other:
chmod -R o-rwx ~
Now if you decide to share the ~/Public folder to everyone, run the next commands:
chmod o+x ~ - allow everyone to descend in the directory (x), but not get a directory listing (r should not be added)
find ~/Public -type f -exec chmod o+r {} \; - allow everyone to read the files in ~/Public
find ~/Public -type d -exec chmod o+rx {} \; - allow everyone to descend into directories and list their contents
I am running apache with mod mono and my asp.net app is using mono sqlite as its db. When i refresh the page twice i get the DB is locked error. The folder it is in is chmod 777. The webapp is creating sqlite.db and sqlite.db-journal but it doesnt seem to be able to delete the journal. Also it has problems when i load the page once. It definitely seems to be a permission problem.
i'm confused. What permissions do i need to set these? i tried precreating the files using 777 and had no luck.
-edit- I didnt find a solution however i thought how silly i was being since i was planning to use mysql for my webapp. So i just ported the code and i no longer had issues.
When creating/deleting a file the directory permission matter.
So, if you really want that, you have to set the containing directory's permissions to 777.
Sample:
$ ls -la
total 21
dr-xr-xr-x 2 me me 1024 May 22 19:19 . #no write permissions to directory
drwxrwxrwt 21 root root 19456 May 22 19:19 ..
-rwxrwxrwx 1 me me 0 May 22 19:19 abc #all permissions to file abc
$ rm abc
rm: cannot remove `abc': Permission denied #abc has 777, but deleting doesn't work
$ chmod 777 . #change directoy's permissions
$ rm abc #now removing works
$ ls #file abc is gone
The reason is that when you delete a file, you actually modify the directory and not the file itself.
Think of a hard link: The file itself will not change when you delete one hardlink to it, but the directory changes.
Sounds more like one instance of the session in apache is blocking the other session, i.e. has the db file open exclusively. Try to let the database(model) run as a singleton (or similar) which all sessions access.