This is with respect to recent issue that has been faced by me. Suddenly post exection of a mv command Linux box went un-responsive on various front, below is the overall description of the issue that happened.
1) move command executed with /* in the destination
# mv -f *.txt /*
2) command has successfully moved the desired content but not to / it moved it to /var
3) along with desired content it also moved content of / folders recursivly to /var location.
4) this resulted in movement of all binary files and folders required for normal OS operations
5) this movement restricted login through SSH/console.
6) post restoration of folders from /var location system got functions normally.
I tried replicating the issue on test Linux Box and it got replicated as below,
[root#TestVM001 ~]# ls -lrt
total 84
-rw-r--r-- 1 root root 4224 Feb 5 17:28 install.log.syslog
-rw-r--r-- 1 root root 38536 Feb 5 17:35 install.log
-rw------- 1 root root 955 Feb 5 17:35 anaconda-ks.cfg
drwxr-xr-x 2 root root 4096 Feb 5 20:03 Desktop
-rw-r--r-- 1 root root 119 Feb 5 20:28 ifcfg-eth0
-rw-r--r-- 1 root root 119 Feb 6 15:17 ifcfg-eth1
-rw-r--r-- 1 root root 44 Mar 1 05:08 student.txt
drwxr-xr-x 3 root root 4096 Mar 14 17:59 admin
[root#TestVM001 ~]# mv -vf * /*
`admin' -> `/var/admin'
`anaconda-ks.cfg' -> `/var/anaconda-ks.cfg'
`Desktop' -> `/var/Desktop'
`ifcfg-eth0' -> `/var/ifcfg-eth0'
`ifcfg-eth1' -> `/var/ifcfg-eth1'
`install.log' -> `/var/install.log'
`install.log.syslog' -> `/var/install.log.syslog'
`student.txt' -> `/var/student.txt'
`/bin' -> `/var/bin'
mv: cannot move `/boot' to `/var/boot': Device or resource busy
mv: cannot move `/dev' to `/var/dev': Device or resource busy
`/etc' -> `/var/etc'
`/home' -> `/var/home'
mv: cannot move `/lib' to a subdirectory of itself, `/var/lib'
`/lost+found' -> `/var/lost+found'
`/media' -> `/var/media'
`/mnt' -> `/var/mnt'
`/opt' -> `/var/opt'
mv: cannot move `/proc' to `/var/proc': Device or resource busy
`/root' -> `/var/root'
`/sbin' -> `/var/sbin'
`/selinux' -> `/var/selinux'
`/srv' -> `/var/srv'
mv: cannot move `/sys' to `/var/sys': Device or resource busy
`/tmp' -> `/var/tmp'
`/usr' -> `/var/usr'
[root#TestVM001 ~]# ls
-bash: /bin/ls: No such file or directory
[root#TestVM001 ~]# ls -lrt
-bash: /bin/ls: No such file or directory
[root#TestVM001 ~]# cd /
.autofsck boot/ lib/ sys/
.autorelabel dev/ proc/ var/
[root#TestVM001 ~]# cd /var/
account/ games/ lost+found/ selinux/
admin/ gdm/ mail/ spool/
anaconda-ks.cfg home/ media/ srv/
bin/ ifcfg-eth0 mnt/ student.txt
cache/ ifcfg-eth1 nis/ tmp/
crash/ install.log opt/ tux/
cvs/ install.log.syslog preserve/ usr/
db/ lib/ racoon/ www/
Desktop/ local/ root/ yp/
empty/ lock/ run/
etc/ log/ sbin/
Questions about this scenarios is,
1) Why mv command resulted in such behavior?
2) Is this behavior is a known Bug or Risk?
3) IS there any known way to restrict this, similar to alias concept usage?
When you do echo mv -f *.txt /* you will see that the last * has been expanded to /var. So you actually asked to move all files in / to /var.
The answers to your questions:
1) Why mv command resulted in such behavior?
mv tried to do exactly what you asked
2) Is this behavior is a known Bug or Risk?
It's not a bug. Unix/Linux do not have prompts "are you sure" but trust the you.
3) IS there any known way to restrict this, similar to alias concept usage?
You should do all normal work as a plain user, not root. The permissions on the important files are such, that they do not allow a normal user to do something harmful.
And when you must do something as root, be very careful!
Trying to move txt files to the root is suspicious: The root partition is small and should be kept for system files. Are the .txt files from Windows?
Related
We are getting the error "permission denied" when trying to write to a file that is owned by a service user and a shared group. In particular that is www-data:www-data and the user trying to write to it is in the group www-data.
There is no acl on none of the parent folders and the permissions to the file and folders are correct.
Here some details:
$ sudo -u deploy id -Gn
www-data
$ ls -lah /tmp
drwxrwxrwt 17 root root 4.0K Jul 11 11:22 .
drwxr-xr-x 23 root root 4.0K Jul 8 10:08 ..
...
-rw-rw-r-- 1 www-data www-data 0 Jul 11 10:50 test
...
$ echo 'hello world' | sudo -u deploy tee -a /tmp/test
tee: /tmp/test: Permission denied
hello world
we tried that on different folders and made sure there is no acl on any of the folders or parents or files...
Unfortunately that is not described in the link stark posted in the comment. And also not in any other page I found until I found an answer here on stackoverflow that clarified it.
2018 two new filesystem configurations got added to sysctl that should prevent regular files and fifos from beeing opened with the O_CREAT flag (as append mode is doing) in directories with the sticky bit set unless the user is the owner of the file. This commit added the settings: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5
To change that behaviour you have to set fs.protected_regular to 0:
sudo sysctl fs.protected_regular=0
Or to persist the change add fs.protected_regular=0 to your sysctl.conf.
side node: since O_CREAT is not deleting or renaming the file I'm wondered why it is connected to the sticky bit. It really is possible to create a file in directories with the stick bit set.
I am very new to linux and am using putty and pscp to move files to a live hosted directory. I would like to rename my recently uploaded dist folder to its actual project name using mv but get a permission denied error. What is the safest and most reasonable way to arrange these files so I can rename them?
lawton#lawtonb:/var/www/html$ ls -la
total 268
drwxr-xr-x 4 root root 4096 Aug 30 16:42 .
drwxr-xr-x 3 root root 4096 Aug 18 23:05 ..
-rw-rw-r-- 1 lawton lawton 253276 Aug 27 18:06 bundle.js
drwxr-xr-x 2 root root 4096 Aug 30 16:42 dist
-rw-r--r-- 1 root root 17 Aug 18 23:24 info.php
drwxr-xr-x 2 root root 4096 Aug 27 18:59 react-youtube
lawton#lawtonb:/var/www/html$ mv dist BTC_Sorter
mv: cannot move 'dist' to 'BTC_Sorter': Permission denied
If this is a one-time rename, your best course of action would be to run mv with sudo, like this:
sudo mv dist BTC_Sorter
If, however, you'd like to have permissions for your user or group, you should do some reading about chown (The link belongs to the Arch Linux wiki, but should be useful regardless of your distro).
In your particular case, the directory dist is owned both by the user and the group root, hence why you'd need to use sudo, chown or simply the root account.
You are not the owner of the file, you need execute the command with sudo
sudo mv src dest
I have two questions regarding linux file permissions.
1)
I have the directory /share with the following permissions:
[root#localhost ~]# ls -ld /share/
drwxrwxrwx. 4 root root 4096 Aug 29 09:15 /share/
Now I go as user erich to that directory and create a file:
[erich#localhost share]$ touch file
[erich#localhost share]$ ls -l
-rw-r--r--. 1 erich share 0 Aug 29 09:30 file
Now as user sven I delete the file:
[sven#localhost share]$ rm -f file
[sven#localhost share]$
How is that possible? Only erich has read/write permissions. I noticed that when I change the /share folder's permission to e.g. 755, then sven cannot delete the file. Is the parent's directory overwriting the files' permissions in it and if yes, why?
2)
I want to share that /share folder to everybody, but at least for sven and erich. I created a group "share" and put those users in it. Then I did the test:
[erich#localhost share]$ mkdir erich
[erich#localhost share]$ ls -l
drwxr-xr-x. 2 erich share 6 Aug 29 09:28 erich
[erich#localhost share]$ touch erich/erich
[erich#localhost share]$ ls -l erich/
-rw-r--r--. 1 erich share 0 Aug 29 09:28 erich
User sven has no write permission to "file". How can I fix that?
Despite the fact that directory permissions are named in the same way, they are kind of different from the file permissions.
For folder:
r is for listing content of the folder
w for creating and deleting files
x for making that directory current (cd in it).
That's why user can delete file with w switched on, even if it has no write permission for the file itself.
Directory permissions doesn't force permission on file you create within it; so, after you create file with touch, you should make it group-writable. You can change permissions of all files in the directory with chmod 775 -R share (-R means recursively).
I have this old Perl script. This script is working from cron on CentOS 6.4. It creates a temporary directory and is trying to unzip files there.
This is a piece of code:
$lg->li("Creating Directory... \n\t$unzip_dir");
mkdir ($unzip_dir, 0777) or my_die("mkdir $unzip_dir failed") unless (-e $unzip_dir && -d $unzip_dir);
However after execution the directory has weird permissions:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drwxrwsr-x 4 buser agroup 4.0K Apr 6 2012 ..
drw-rwSr-- 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
The umask for user auser is a 0002.
Why the new directory has no execution permission? Any idea, how this can happen?
The weird permissions are caused by the setgid bit on the parent directory in combination with an unusual umask:
Look at the permissions of the parent directory, the first line:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drw-rwSr-- 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
Notice it has rwxrwsr-x which means that the setgid bit is set. The setgid bit on a directory causes new files in the directory to be created with the same group as the directory. New directories inherit the setgid bit from their parent.
A umask of 0113 will cause the strange permissions you're seeing. That is an unusual umask, the default is 0022. The umask is set in the environment executing the script, or directly in the script itself.
Don't worry about 0777 after mkdir in your script: mkdir $dir, 0777 means "create $dir without interfering with the present umask". 0777 is the default and can be safely omitted.
Try setting the umask directly in your script:
umask 0022;
$lg->li("Creating Directory... \n\t$unzip_dir");
mkdir ($unzip_dir) or my_die("mkdir $unzip_dir failed") unless (-e $unzip_dir && -d $unzip_dir);
should cause:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drwxr-sr-x 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
New directory permissions are rwxr-sr-x which is more normal. Notice that the setgid bit is still set because of the parent directory.
Oh, you might wonder why the setgid bit is sometimes lowercase 's' and sometimes uppercase 'S'. That depends on the executable bit. Lowercase s means the executable bit is set, uppercase means it's not set:
$ mkdir foo
$ ls -l
drwxr-xr-x 2 johan johan 4096 Dec 30 17:22 foo
$ chmod g+s foo
$ ls -l
drwxr-sr-x 2 johan johan 4096 Dec 30 17:22 foo
$ chmod g-x foo
$ ls -l
drwxr-Sr-x 2 johan johan 4096 Dec 30 17:22 foo
Your code looks correct to me.
Confirming on my system:
perl -e 'mkdir("foo", 0777);'
drwxr-xr-x 2 user user 512 Dec 30 10:48 foo
mkdir is affected by your umask. A funky umask can do funky things.
What does this yield for you?
perl -e 'printf("%04o\n", umask());'
I get this:
0022
Which is why my folder is created 0755 when I ask for 0777.
I've debugged script and found source of the problem.
The problem caused by tar.gz archive sent to us by one of our submitters. These tar files having directory without execution permission set. I have no idea how they achieve such result.
One more problem - the Gnu Tar have no key to prevent restoring files and directories permissions.
So after extracting archive with wrong permissions I have to recursively set right permissions on the all files and directories in the archive.
Thank you everybody.
It means that the setuid and setgid bits have been set.
The setuid (set user id) is a permission bit, that allows the users to exec a program with the permissions of its owner.
The setgid (set group id) is a bit that allows the user to exec a program with the permissions of the group owner.
http://linuxg.net/how-to-set-the-setuid-and-setgid-bit-for-files-in-linux-and-unix/
I see "builds01" directory when I do ls,when I "cd builds01" on that directory I get the following error,any idea why I am getting below error for a directory that exists/s
<user:/prj/com/builds>ls -la
total 8
dr-xr-xr-x 3 root root 4096 2013-05-29 00:53 .
dr-xr-xr-x 4 root root 4096 2013-05-29 00:53 ..
drwxr-xr-x 2 root root 0 2013-05-29 00:53 builds01
<user:/prj/qca/builds>cd builds01/
-bash: cd: builds01/: No such file or directory
I had an issue once such as this. It’s possible that this is on mount point and not a real directory. Another possibility is there may be white space before the name of the directory that was somehow created.
Try to do: cd \ builds01 or even cd “builds01” and see if that works.
If all else fails attempt to use something such as filezilla or winscp and navigate to the path.
Check out user permissions: you are not root at the moment.
The folder is readable only by root (and belongs to root).