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.
Related
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.
Is it possible on Linux or MacOSX to prevent a Unix domain socket file (e.g. in /tmp) that is currently bound from being deleted? I want a mode 0777 socket that users can connect to but that users cannot delete while the daemon is running.
Right now a normal user can 'rm' the socket, preventing anyone else from accessing it until the daemon is restarted. Seems like it should be 'busy' if it's bound.
You could make a new subdirectory and set read only permissions on the directory after you make the socket:
mkdir /tmp/blah
cd /tmp/blah
# do stuff to create /tmp/blah/socket
chmod 555 /tmp/blah
rm /tmp/blah/socket
rm: cannot remove /tmp/blah/socket: Permission denied
(or the equivalent to that from C / your language of choice)
It depends entirely on the directory that contains the socket. /tmp is somewhat special in that it has the "sticky bit" set on the directory (if you execute ls -ld /tmp you will see the permissions field is usually: drwxrwxrwt or, more usefully, mode 1777. That sticky bit (the t at the end) is important when set on a directory. Quoting man chmod:
The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents
unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the re‐
stricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older
systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit.
This is exactly what you want - file-system level protection against a user removing the file. It is also 100% portable to all modern UNIX-like environments.
So, if you are creating your endpoint in /tmp you already have the protections you want. If you want to create the endpoint elsewhere, for example /opt/sockets, simply chmod 1777 /opt/sockets. The last part of the "trick" to getting the protections you want is to ensure that the root user is the actual owner of the endpoint. If the endpoint is owned by user fred then fred will always be able to delete the endpoint, which may well be a desirable thing. But if not, simply chown root:root /path/to/endpoint.
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 am currently learning LINUX commands and I am wondering how to run commands within the .plan file.
For example i want to a message as would be output from the ~stepp/cosway programs.
I typed ~stepp/cosway "HELLO" but it didn't work. What is the command for that?
Also how do I set all files in the current directory and all its subdirectories recursively to have a group of admin?
The .plan file is a plain text file that is served by the fingerd daemon. For security reasons, it's not possible to execute commands from that file, unless you modify and recompile fingerd on your machine to do so.
Concerning the second part of your question, use chgrp:
$ chgrp -R admin *