It is about GNU .bash_history.
Required to disable .bash_history file creation for 2 specific users.
So when those users logging on .bash_history should not be created.
it is required to remove existing .bash_history file for some specific users and this file should never appear back.
Any ideas? thanks a lot in advance
This works for me:
chmod 0 .bash_history
Related
I have a directory that I want to share in a cluster so that another user can
use my program and do some changes to her needs.
I have root access and I just basically did
$sudo cp dir /home/visitors/usr1
When I checked the directory and their contents, I found that they belong to root, which was good so far, so I did
$chown *.* usr1
Now the directory and the files belong to usr1 and with the same permissions that I had originally, namely
-rw-r--r-- 1 usr1 users
(also the group is the same as mine).
Now, when I try to edit a file as usr1 in emacs, the window stays empty and below I can see a message:
Creating directory: permission denied, /home/visitors/usr1/.emacs.d/
If I try to edit a file, but using vim, I can save changes, but a warning is raised:
E138: Can't write viminfo file /home/visitors/usr1/.viminfo!
Any idea how to override this type of behaviour and be able to edit normally in both vim and emacs?
The error messages do not say anything about not being able to read or write the file you are editing; your usr1 does not seem to have write permissions on /home/visitors/usr1. Check with
$ ls -ld /home/visitors/usr1
The files that cannot be written do not match *.*, they are .*
I think you need to change permission on those as well. Try ls -la and see what the owner and permissions are.
I want to prevent a user from modifying a file but I can't seem to get it to work using standard permissions.
The file is file.jpg, which is in the folder 2012/.
File details:
-r--r--r-- 1 root root 10294 Feb 19 2013 file.jpg
Folder details:
drwxr-xr-x 2 charly charly 36864 Aug 27 15:38 2012/
My intention is to prevent the user from renaming the file but with the permissions as they are he's able to.
What am I missing?
You don't change a file when renaming it or moving it in the same filesystem, because a file is really an inode (which may have zero, one or more filenames in directories).
Renaming a file is an operation inside the relevant directories (not on the file itself). Perhaps removing write access to the directory might help (but if the user owns the directory, he could change again these permissions on the directory with chmod). Read also more about sticky bit on directories.
BTW, the user could also hard link that same file, i.e. add a new filename to it. Then each filename is refering to the same file.
The permissions on a file prevent/allow access to the file. Renaming a file does not involve changing the file itself - renaming is actually a change to the directory.
Try changing the directory permissions to:
dr-xr-xr-x
and see what happens.
If I would like to lock a file as read-only. Even root can not use an editor to modify it, just allowing any program to open it read-only.
Any suggestions?
There is an "immutable" bit for files.
Programs (even running as root) won't be able to tamper with the file. Of course, root can un-do the bit, but most programs (especially non-malicious ones) won't get past it.
Set it with
sudo chattr +i file
you should have root perms
sudo chattr +i file
You can use Perl or another language to create a file lock
How do I lock a file in perl
But, root could kill the process can gain access to the file.
I have a folder /cygwin/d/myfolder/
And everytime I save files there, from cygwin if i do an ls -la I see that the files are given permission 000. That actually causes me quite a bit of problem as I rsync this folder to my server and none of the files are accessible. How can I get the files to automatically get a reasonable permission?
Have a read through the answers at this link:
http://cygwin.1069669.n5.nabble.com/vim-and-file-permissions-on-Windows-7-td61390.html
The solution there worked for me also:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
Then close all Cygwin processes, open a new terminal and ls -l on your files again.
Explanation:
By default, Cygwin uses the filesystem's access control lists (ACLs) to implement real POSIX permissions. Some Windows-native program or process may create or modify the ACLs such that Cygwin computes the POSIX permissions as 000. With the noacl mount option, Cygwin ignores filesystem ACLs and only fakes a subset of permission bits based on the DOS readonly attribute.
Check to make sure that your umask is set correctly with the umask command. If your umask is say 0777 that subtracts from the permissions of new files and will end up with 000 permissions. There's probably several other possibilities to consider beyond that.
If your id is not set up correctly in /etc/passwd and /etc/group that can also cause ls to show unexpected results. Check the permissions of the folder. Also check the Windows permissions with the getfacl command. Maybe also check the mount command.
In above answer, solution was proposed:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
And in that answer there was this comment:
When I try this, all my files are -rw-r--r-- no matter what chmod() I do. I can't mark the files as executable; it just reverts to 0644. (umask==0022)
I had this same problem, but it manifested in inability to execute DOS batch files (*.bat) when running Cygwin ksh or mksh. I stumbled across this website: http://pipeline.lbl.gov/code/3rd_party/licenses.win/cygwin-doc-1.4/html/faq/ which contains this helpful advice:
Note that you can use mount -x to force Cygwin to treat all files under the mount point as executable. This can be used for individual files as well as directories. Then Cygwin will not bother to read files to determine whether they are executable.
So then cross-referencing with this page - https://cygwin.com/cygwin-ug-net/using.html#mount-table - with its advice:
cygexec - Treat all files below mount point as cygwin executables.
I added cygexec to fourth field of my fstab. This did it. My .bat is now executable inside ksh/mksh, which is necessary since I'm running a Jenkins job that calls a Korn shell stack 3 files deep, that I have no modifiable control over. I just needed the .bat to run!
Update: the solution above wasn't quite what I needed, on further testing. It resulted in some executables such as javac and cl to behave oddly (the utilities would print their usage and exit). I think what I needed instead of 'cygexec' was just 'exec'. As the same page notes:
exec - Treat all files below mount point as executable.
On my Win7 PC files were usually
----------+ 1 David None 69120 Jun 17 13:17 mydoc.txt
I tried all of above no luck
Turned out I still had some old historical mount entries in my .zshrc
I deleted these and Bob's your Uncle problem gone away!
Why is it possible to touch a write-protected file?
Shouldn't the following give an error?
$ touch test.txt
$ chmod a-w test.txt
$ ls -l test.txt
-r--r--r-- 1 name group 0 Jun 13 09:14 test.txt
$ touch test.txt && echo OK
OK
$ ls -l test.txt
-r--r--r-- 1 name group 0 Jun 13 09:15 test.txt
Does touch change permissions, touch the file, and change permissions back? Why would it do that?
Given this behavior, if I really want to protect a file so that I (my user) will never (unintentionally) change, remove or change its timestamp in the future -- how can I do it?
(Sorry, not strictly programming-related, but slightly, and probably of interest to many programmers.)
From the touch (coreutils) documentation:
If changing both the access and
modification times to the current
time, `touch' can change the
timestamps for files that the user
running it does not own but has write
permission for. Otherwise, the user
must own the files.
The execution permissions of the directory that the file contains dictates the ability to delete or modify the inode information for the entry in the directory that is associated with the file.
As the comment below indicates I have glossed over the technical reason but instead offered a reasoning why the behavior might not be as expected. Since you can execute in the directory there are a number of things you can do to tinker with the file and I am going to leave it at that.
If you want to stop anyone but root from modifying a file the best method is to use the chattr +i filename on the file. Even root will not be able to perform any actions on it without running chattr -i on it. This applies to Linux so YMMV.
Here's the relevant output from : strace "touch test.txt"
open("test.txt", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_LARGEFILE, 0666) = -1 EACCES (Permission denied)
futimesat(AT_FDCWD, "test.txt", NULL) = 0
It indeed gets a "Permission denied error" on the open(2) system call regarding EACCES. See relevant section in utimes(2) man page.
However, it does succeed in updating the timestamp using the futimesat(2) system call.
As others have indicated, it looks like the directory permissions hold the rights to update access/moficiation timestamps.
You can, however change the attribute of a file to immutable using:
chattr +i test.txt
Note: Only root can do this, and it's a very harsh way to disable access to files. But in extreme cases, it can be useful. In addition, this is an ext2/3/4 feature, not available on other filesystems as far as I know.
You can update the modification time if you own the file, regardless of write permission. (It is not related to any permission on the directory.)
From POSIX.1-2008:
Only a process with the effective user ID equal to the user ID of the file, or with write access to the file, or with appropriate privileges may use futimens() or utimensat() with a null pointer as the times argument or with both tv_nsec fields set to the special value UTIME_NOW. Only a process with the effective user ID equal to the user ID of the file or with appropriate privileges may use futimens() or utimensat() with a non-null times argument that does not have both tv_nsec fields set to UTIME_NOW and does not have both tv_nsec fields set to UTIME_OMIT. If both tv_nsec fields are set to UTIME_OMIT, no ownership or permissions check shall be performed for the file, but other error conditions may still be detected (including [EACCES] errors related to the path prefix).
In layman's terms, using the touch command will update or create a file without editing/modifying its contents. Because the command doesn't(and can't) write or erase anything from the file, it can be used on write-protected files. See the wiki on the touch command for more information: http://en.wikipedia.org/wiki/Touch_(Unix)