~/Library/Messages directory no longer accessible on macOS Mojave - macos-mojave

I used to access the chat.db in this directory via sqlite3 but this obviously no longer works; in addition the directory is no longer accessible as can seen below:
$ cd ~/Library/Messages
$ pwd
/Users/moshe/Library/Messages
$ ls
ls: .: Operation not permitted*

macOS Mojave now protects certain locations. You can allow Terminal (and other apps) to access these locations by going to System Preferences > Security & Privacy > Privacy > Full Disk Access.
See “Full Disk Access” in Privacy Preferences help.

Related

Unable to SSH after enforcing SELinux?

I have modified ”SELINUX=enforcing“ in /etc/selinux/config.But after restarting the machine,I can't ssh to my machine.
Prompt that
/bin/bash: Permission denied
When you edited the SELINUX for the first time or when switching between different types of policy, you need to relabel the filesystem. The below steps will do the relabel process automatically as shown in the procedures:
Restart server
reboot
On the GRUB display, press “e” to start editing the selected menu item.
Perform a break at an early stage of the boot process by typing 「rd.break」 at the end of the line starting
with kernel=.
kernel=... UTF-8 rd.break
Once ready press CTRL+X to start the boot process.
Check write access on the /sysroot mount point. By default this mount point is mounted only with the read-only (ro) access
mount | grep sysroot
=/dev/mapper/rhel-root on /sysroot type xfs (ro,relatime,attr2,inode64,noquota)
Remount the sysroot directory with read & write access.
mount -o remount,rw /sysroot
mount | grep sysroot
=/dev/mapper/rhel-root on /sysroot type xfs (rw,relatime,attr2,inode64,noquota)
Enter chroot system
chroot /sysroot
(new prompt) sh-4.4#
Force file-system relabeling. Next time when you will reboot the system, it will relabel the filesystem for
SElinux automatically.This usually occurs when labeling a file system for SELinux for the first time, or when
switching between different types of policy, such as changing from the targeted to the strict policy.
touch /.autorelabel
Exit the chroot. Reboot the machine
exit
logout or reboot (it will take time)
Now you should be able to login with ssh.

ls doesn't show any output in ssh connected to an Debian 9 VM instance in Google Cloud Platform

this might be a dumb question, but I checked everywhere and there's no direct answer to it.
I set up both SSH keys successfully and I can connect to my instance via terminal, but when I do "ls", it doesn't show me any output. I am using iTerm2 with zsh on my Mac but I don't think this is an issue.
Can anybody give me a hint? Thanks!
When you access a VM through SSH, your working directory is the home directory of the user specified with the SSH command, i.e. /home/username. In case you access as root, the working directory will be /root.
You can check it through the command pwd
If it is a brand new machine, it is normal that the output of 'ls' is empty since in your home directory no file matches the filters of 'ls' with no parameters. The reason is that 'ls' doesn't show filenames starting with a dot ('.') because in the Linux convention they are hidden unless you run ls -al.
You can try again with $ ls -al and you will be able to see hidden files and directories as well.
On the other hand you can create as well first an empty file and then running again 'ls':
$ touch file
$ ls

nfsnobody User Privileges

I have setup an NFS file share between two CentOS 6, 64 machines. On the server the folder being shared was originally owned by the root user. On the client it turned up as being owned by nfsnobody. When I tried to write to the folder from the client I got a permissions error. So I changed the folder ownership on the server to nfsnobody and chmod'd it to 777. However, still no joy - I continue to get a permissions error. Clearly, there is more to this. I would be much obliged to any Linux gurus out there (I personally wouldn't merit being called anything more than a newbie) who might be able to help fix this issue.
Edit - I should have mentioned that trying to write to the shared folder from the client actually manages to create a file entry. However, the file size is 0 and the permissions error is reported.
The issue here is to do with the entry in /etc/exports. It should read
folder ip(rw,**all_squash**,sync,no_subtree_check)
I had missed the all_squash bit. That apart, make sure that the folder on the server is owned by nfsnobody. On my setup both my client and server nfsnobodies ended up with a user id if 65534. However, it is well worth checking this (/etc/groups) or else... .
Here are a couple of useful references
How to setup an NFS SErver
NFS on CentOS
For the benefit of anyone looking to setup an NFS server I give below what worked for me on my CentOS 6 64bit machines.
SERVER
yum install nfs-utils nfs-utils-lib - install NFS
rpm -q nfs-utils - check the install
/etc/init.d/rpcbind start
chkconfig --levels 235 nfs on
/etc/init.d/nfs start
chkconfig --level 35 rpcbind on
With this done you should create the folder you want to share
mkdir folder
chown 65534:65534 folder
chmod 755 folder
Now define the folder to be shared/exported. Use your favorite text editor (vi or whatever) to
open/create /etc/exports
folder clientIP (rw,all_squash,sync,no_subtree_check)
Client
Install, check, bind and start as above
mount -t nfs serverIP:folder clientFolderLocation
If all goes well you should now be able to write a little script on your client
<?php
$file = $_SERVER['DOCUMENT_ROOT']."/../nfsfolder/test.txt";
file_put_contents($file,'Hello world of NFS!');
?>
browse to it and find that test.txt now exists on the server with the content "Hello world of NFS". In the example I have placed my mounted drive one level before document_root.

Could not update .ICEauthority file

Recently I changed the permissions of the file system and gave myself all the rights. I logged out of the system and I couldn't log back in. I got the error message
Could not update ICEauthority file /home/marundu/.ICEauthority</>
I did a live boot with a Fed 17 disc and replaced my .ICEauthority file with the live-user version and it worked for a time, until I logged out again. Now, the login progress screen is all that shows. I can log into command mode (Ctrl-Alt-F2) but I can't sudo - I get the error messages:
sudo:/usr/libexec/sudoers.so must be only writable by owner and sudo: fatal error. Unable to load plugins.
I just found a good link on Ubuntu:
Ask Ubuntu: ICEauthority permissions problem
Some things to note:
I tried the obvious things like changing file permissions, but found my whole home directory was somehow owned by root. I believe this was due to a failed package update.
I used a recovery disk (Knoppix ISO) for ease of use: Better UI
When mounting the bad home partition, I used the most common Linux file type (Ext4)
I used 'sudo mount -o r,w -t ext4 /dev/sda1 /mnt'
When changing ownership, I used the numeric user:group specification, since the recovery disk doesn't have the symbolic users and groups: 'sudo chown -R 1000:1000 /mnt/home/userdir'
I verified that /home/userdir had rwx for owner, r-x for group / other. This is noted as a valid set of permissions for ICEauthority; others can work. See the linked discussion.
Hope that helps someone...
I got the “Could not update ICEauthority file” error and found that my home partition was in "Read-Only" mode. Thus, this error made sense.
The real question was what caused the "Read-Only" attribute on the partition. I ran "dmesg | read-only" and found that there were serious errors with the file system on my home partition which the kernel had set to "read-only during the boot process.
I then booted from a USB key (CDROM would do as well) and ran "sudo fsck /dev/sdXY" where /dev/sdXY is the partition containing my home directory. fsck corrected a number of file system errors on my home partition.
I then reboot after removing the USB key/CDROM and the problem went away.
Bottom line: Check if your home partition has file system errors. They might be the cause of this error. If so, run fsck from an external device on the partition containing your home directory.

Is there a way I can have a VM gain access to my computer?

I would like to have a VM to look at how applications appear and to develop OS-specific applications, however, I want to keep all my code on my Windows machine so if I decide to nuke a VM or anything like that, it's all still there.
If it matters, I'm using VirtualBox.
This is usually handled with network shares. Share your code folder from your host machine and access it from the VMs.
Aside from network shares, another tool to use for this is a version-control system.
You should always be able make a normal network connection between the VM and the hosting OS, as though it were another computer on the same network. Which, in some sense, it is.
I do this all the time.
I have a directory in a Windows drive that I mount in my host ubuntu 12.04.
I run virtualbox ubuntu 13.04 as a guest.
I want the guest to mount the Windows directory with full non-root permissions.
I do almost all my work from a bash shell, so this method is natural for me.
When searching for methods to automatically mount virtualbox shared folders,
reliable and correct methods are hard to distinguish from those that fail.
Failures include getting and setting permissions, as well as other problems.
Methods that fail include:
modifying /etc/fstab
modifying /etc/rc.local
I am fairly certain that rc.local can be used,
but no methods I have tried worked.
I welcome improvements on these guidelines.
On virtualbox 4.2.14 running nautilus (bash terminal) on an ubuntu 13.04 guest,
Below is a working method to mount Common (sharename)
on /home/$USER/Desktop/Common (mountpoint) with full permissions.
(Note the ‘\’ command continuation character in the find command.)
First time only: create your mountpoint, modify your .bashrc file, and run it.
Respond with password when requested.
These are the four command-lines needed:
mkdir $HOME/Desktop/Common
sudo echo “$USER ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers
find $HOME/Desktop/Common -maxdepth 0 -type d -empty -exec sudo \
mount -t vboxsf -o \
uid=`id -u $USER`,gid=`id -g $USER` Common $HOME/Desktop/Common \;
source ~/.bashrc # Needed if you want to mount Common in this bash.
All other times: simply launch a bash shell.
The find command mounts the shared directory if the mountpoint directory is empty.
If the mountpoint directory is not empty, it does not run the mount command.
I hope this is error-free and sufficiently general.
Please let me know of corrections and improvements.