I wrote a little program, where i mounted an encrypted volume after the user inserts the password with veracrypt an showed the content to the user in a specific way inside my programm. Everything works fine, but i want to prevent that the volume is shown in Nautilus.
The following command mounts the volume:
"veracrypt -m ro /path/to/file/file -p" + pw
Veracrypt help command shows:
--fs-options=OPTIONS
Filesystem mount options. The OPTIONS argument is passed to mount(8)
command with option -o when a filesystem on a VeraCrypt volume is mounted.
This option is not available on some platforms.
But i'm not able to find a mount option for linux-mount command, which will do the job. Is there any? What can i do?
A simple workaround may be to mount the volume to a directory that begins with a .. These directories should not be visible in most file managers without specifying they should show hidden files/folders.
Of course, obscuring the folder isn't perfect and is no substitute for setting proper access control specifies via chmod.
Related
I'd like to have a program executed before a mount attempt is made for a particular device/share/mount.
For example, I'd like for autofs/amd to control /data/{1..10}, and when a process opens /data/4 (and /data/4 is not currently mounted), a script is invoked, such as '/usr/local/bin/preparedata 4' (4 being the mount point name within the autofs controlled directory), prior to the attempt to mount.
For example, I could dynamically attach an iSCSI LUN (which would be referenced in the autofs map), or startup a remote system/VM which has an NFS export (which is specified in the map).
I'd be glad to add details if missing.
Update: I've noticed that systemd appears to be intercepting open() calls, is there some way to do this particularly in systemd?
Autofs itself can run a custom script or program to dynamically provide "the map", i.e. the mount options and arguments autofs uses for mounting.
As an example, to automount home directories from an NFS-server one may prefer to use a pattern like "/home/user12/user123456" for the homedir paths to limit the number of sub-directories on a server when there are many users.
To dynamically mount such home directories, you could put this in your /etc/auto.master:
/home program:/usr/local/sbin/autofs-home-mapper.sh
The script /usr/local/sbin/autofs-home-mapper.sh could look like this:
#!/bin/bash
echo "-fstype=nfs4,relatime nfs.example.com:/exported/${1%????}/${1}"
When the local directory /home/johndoe is accessed, autofs will run the script
with one argument: johndoe
Output of this script will then be:
-fstype=nfs4,relatime nfs.example.com:/exported/joh/johndoe
...which is then used by autofs to mount /home/johndoe
Don't forget to set eXecute permission on the script, as it can be difficult to track down a bug like that.
More information in man 5 auto.master (look under "map-type") and man 5 autofs.
Take a look at x-systemd.requires=, and x-systemd.after= for hooks executed before mounting.
These options can be specified inside /etc/fstab.
Related question: Hook before an .automount unmounts.
I am trying to do a soft link from one directory to another, the directory I am trying to access I have read and execute. However, its parent directory I do NOT have execute permissions.
Is there a way to do a soft link, to my desired directory without giving me execute permission to the parent directory?
Below is the code I used:
ln -s /home/dir1/dir2/desired_directory symbolic_link_name
the link just comes up as red with grey background.
Thank you.
Although this is not possible with symlinks, you could do it with mount --bind. Note that if the whole point is to circumvent security, then this is probably a very bad idea.
Your command would be
mount --bind /home/dir1/dir2/desired_directory mount_dir
There are a few issues to be aware of:
The target directory mount_dir must exist before (same as any mount point)
Root access is required to execute the mount commmand
The created "link" will not persist after a reboot unless a corresponding line is added to /etc/fstab
If the origin directory contains mounted file systems, these will not be transferred to the target. The mount points will appear as empty directories.
Using mount --bind may be considered bad practice because most programs are not aware that the "link" is not a standard directory. For instance it allows the creation of loops in the directory tree which make any tree parsing application (think "ls -R") enter a possibly infinite loop.
It may be hazardous when combined with recursive delete operations. See for instance Yet another warning about mount --bind and rm -rf.
Symbolic links are not a way to circumvent permissions set on their targets. No, there is no way to do what you want. If it was possible it would be a serious security issue.
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!
I have just formatted an external hard disk using this command:
$ sudo mkfs -t ext3 /dev/sdc1
However, once this is done, whenever I want to create a directory
or file in this hard disk, it always ask for password (i.e. permission requirement).
Is there a way I can disable that?
Note that I can't format the partition with mkfs unless I use sudo.
Please advice.
If you mount the partition at /media/foo, then try this:
sudo chmod 1777 /media/foo
It'll act like /tmp does at that point. So any user can create a folder / file in there, but you can only delete your own files.
I would recommend you asking the same question at ServerFault. I think you'll get a better answer over there.
I have a bunch of long-running scripts and applications that are storing output results in a directory shared amongst a few users. I would like a way to make sure that every file and directory created under this shared directory automatically had u=rwxg=rwxo=r permissions.
I know that I could use umask 006 at the head off my various scripts, but I don't like that approach as many users write their own scripts and may forget to set the umask themselves.
I really just want the filesystem to set newly created files and directories with a certain permission if it is in a certain folder. Is this at all possible?
Update: I think it can be done with POSIX ACLs, using the Default ACL functionality, but it's all a bit over my head at the moment. If anybody can explain how to use Default ACLs it would probably answer this question nicely.
To get the right ownership, you can set the group setuid bit on the directory with
chmod g+rwxs dirname
This will ensure that files created in the directory are owned by the group. You should then make sure everyone runs with umask 002 or 007 or something of that nature---this is why Debian and many other linux systems are configured with per-user groups by default.
I don't know of a way to force the permissions you want if the user's umask is too strong.
Here's how to do it using default ACLs, at least under Linux.
First, you might need to enable ACL support on your filesystem. If you are using ext4 then it is already enabled. Other filesystems (e.g., ext3) need to be mounted with the acl option. In that case, add the option to your /etc/fstab. For example, if the directory is located on your root filesystem:
/dev/mapper/qz-root / ext3 errors=remount-ro,acl 0 1
Then remount it:
mount -oremount /
Now, use the following command to set the default ACL:
setfacl -dm u::rwx,g::rwx,o::r /shared/directory
All new files in /shared/directory should now get the desired permissions. Of course, it also depends on the application creating the file. For example, most files won't be executable by anyone from the start (depending on the mode argument to the open(2) or creat(2) call), just like when using umask. Some utilities like cp, tar, and rsync will try to preserve the permissions of the source file(s) which will mask out your default ACL if the source file was not group-writable.
Hope this helps!
It's ugly, but you can use the setfacl command to achieve exactly what you want.
On a Solaris machine, I have a file that contains the acls for users and groups. Unfortunately, you have to list all of the users (at least I couldn't find a way to make this work otherwise):
user::rwx
user:user_a:rwx
user:user_b:rwx
...
group::rwx
mask:rwx
other:r-x
default:user:user_a:rwx
default:user:user_b:rwx
....
default:group::rwx
default:user::rwx
default:mask:rwx
default:other:r-x
Name the file acl.lst and fill in your real user names instead of user_X.
You can now set those acls on your directory by issuing the following command:
setfacl -f acl.lst /your/dir/here
in your shell script (or .bashrc) you may use somthing like:
umask 022
umask is a command that determines the settings of a mask that controls how file permissions are set for newly created files.
I don't think this will do entirely what you want, but I just wanted to throw it out there since I hadn't seen it in the other answers.
I know you can create directories with permissions in a one-liner using the -m option:
mkdir -m755 mydir
and you can also use the install command:
sudo install -C -m 755 -o owner -g group /src_dir/src_file /dst_file