SIGSEGV

[knezi]

SIGSEGV

[sloonz]

Hello,

Sorry for the delay, I just noticed that my Github account sent notifications to an old email address…

The config option must be set to the pre-rewrite path (config=/mnt/home/knezi/config/rewritefs). You’re not the first person to make the mistake, I should probably put an entry in the FAQ…

[knezi]

Thank you for the reply, but still getting SIGSEV.
rewritefs -o config=/mnt/home/knezi/config/rewritefs /mnt/home/knezi /home/knezi
rewritefs -o config=/mnt/home/knezi/config/rewritefs /mnt/home /homei

[sloonz]

Don’t you have another error message before the crash ?

You can have more debug traces with rewritefs -f -v 5 ...

You can also recompile with debug flags (make CFLAGS=-g clean all) and then run inside gdb (gdb --args ./rewritefs -f ... and then gdb command run) to get a full stack trace of the crash (using bt command in gdb once the crash occurs)

Please also try last commit, it replaces some crash with proper error messages.

[knezi]

I am probably not getting how this works. Sorry, but when I copy last command and run it, there is no SIGSEV. I guess it works, but there is no process called rewritefs, but it is intended behaviour, right?
Now I just do not know how to persuade rewritefs to move my files.
Also with parametrs -f -v 5 will print nothing.

[sloonz]

I guess it works, but there is no process called rewritefs, but it is intended behaviour, right?

No, this is not intended. After running the run command in the GDB prompt, you should have a rewritefs process. And when rewritefs crash, you should have the GDB prompt again where you can use the bt command.

A simpler alternative under ArchLinux is run rewritefs, wait for the crash, and just run coredumpctl gdb and then use the bt command.

Also with parametrs -f -v 5 will print nothing.

It will print nothing at startup, but should show information at first access on the mounted filesystem (for example at ls /home/knezi).

[knezi]

Sorry for the big delay. I have tried to backtrace it:

(gdb) run -o config=/mnt/home/config/rewritefs /mnt/home /home -v 5 -f
Starting program: /tmp/rewritefs/rewritefs -o config=/mnt/home/config/rewritefs /mnt/home /home -v 5 -f
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff73ed0ca in strlen () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff73ed0ca in strlen () from /usr/lib/libc.so.6
#1  0x0000000000403112 in parse_args (argc=8, argv=0x7fffffffe5a8, outargs=0x7fffffffe4a0) at rewrite.c:366
#2  0x00000000004026e7 in main (argc=8, argv=0x7fffffffe5a8) at rewritefs.c:565

The problem is in parsing arguments, but I don't see anything.

[sloonz]

Looks like canonicalize_file_name() fails to read the source directory /mnt/home. Are you sure that it exists ?

Last commit should show an explicit error message.

[knezi]

Ok. If the directory exists, I get:

fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option

[jdunn0]

In *nix systems you mount file systems at various mount points.
Mount points are basically empty directories.
For example, you have a cdrom device at /dev/sr0 you want to mount at /mnt/cdrom then this is what you do:

1. Create the empty directory if needed by running: mkdir /mnt/cdrom
2. Do the mount by running: mount /dev/sr0 /mnt/cdrom

If you had a second cdrom device at /dev/sr1 and tried to mount it at /mnt/cdrom while that directory had /mnt/sr0 mounted to it you would either not be able to access the /dev/sr0 mount or you wouldn't be able to mount the /dev/sr1 mount until you unmounted the /dev/sr0 mount first.

In the case of some directories you usually have a device like /dev/sdb1 for example that contains the home directories that are mounted to the empty directory home on the root file system (/).

The way rewritefs would normally be set up in this example is

1. You configure your system to mount /dev/sdb1 to /mnt/home (the empty directory needs to be created first of course) instead of /home.
2. In the now empty /home you create empty directories to use as rewritefs mount points for each user you want to have a home directory to use rewritefs with.
3. Mount rewritefs to each of the mount points.
   In your case, running 'rewritefs -o config=/mnt/home/knezi/config/rewritefs /mnt/home/knezi /home/knezi' as you did.
   If /home/knezi is an empty directory then you shouldn't be getting the message "fuse: mountpoint is not empty".
   If you are currently have files in /home/knezi you are using then that would explain the message.
   This could happen if you have a desktop environment like gnome or kde running under that user.
   You need to setup the mount points with rewritefs with out anything like a desktop environment running that is using the path '/home/knezi'.
   This also assumes that you have a separate partition or hard drive set up just for home directories to mount at /mnt/home.
   You could just have /home as a real folder on your root file system, in which case setting up rewritefs would be a little trickier.

[sloonz]

Not much to add to jdunn0 great explanation (thanks ;)) except two points :

1. If you are sure that /home contains nothing but useless files like .bash_history/.Xauthority, you can force fuse to mount anyway with -o nonempty
2. If /home was a real folder in the root filesystem, it’s really easy to do the migration : mv /home /opt/home (or another place), and then you can mount it with rewritefs /opt/home /home

[knezi]

Thanks for the great explanation.
I have followed all the steps and edit fstab. There are still two problems:
Firstly, I have got systemd and it (dunno why) firstly try to mount rewritefs dir and it fails because of non-existence of the config file (which is on another not yet mounted partition).

• I can move the config file to the different place
• or persuade systemd that home.mount has dependency, I prefer this way, but not sure how to do it.
  How did you set it on your PC?

Secondly, after fallback to emergency mode, I restarted home.mount and got following:

Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)

However, it works. Only when I try to start X server after logging, I get error: timeout in locking .Xauthority. To solve this, I just run as root pkill -U knezi and Xserver will just start.

I am really confused with this behaviour. Any ideas?
Thanks.

[sloonz]

How did you set it on your PC?

I did it before systemd with /etc/rc.local and did not take time to look at how I could do it with systemd. If you made a systemd unit for rewritefs I think it just amount to adding After=opt-data.mount (if your files are in /opt/data) for example.

I am really confused with this behaviour. Any ideas?

This may happen if you run rewritefs after your X session. Make sure that rewritefs is up before the display manager to be extra sure.

[sloonz]

Closing for now ; feel free to reopen if you still have any issue

[knezi]

Thanks for help. It works.
My systemd service /etc/systemd/system/rewritefs.service:

Description=RewriteFS
RequiresMountsFor=/mnt/home

[Service]
Type=forking
User=knezi
ExecStart=/usr/local/bin/rewritefs -o config=/mnt/home/knezi/config/rewritefs,allow_other /mnt/home /home


[Install]
WantedBy=default.target

I want to just ask about permissions. I run it as regular user, but than I cannot operate with files owned by root. Is this intented behaviour? Should it be run as root? Will file permissions be preserved?

[jdunn0]

The line
ExecStart=/usr/local/bin/rewritefs -o config=/mnt/home/knezi/config/rewritefs,allow_other /mnt/home /home

Should be
ExecStart=/usr/local/bin/rewritefs -o config=/mnt/home/knezi/config/rewritefs,allow_other /mnt/home/knezi /home/knezi

The reason is that rewritefs works per home directory, not on the path where home directories are stored.
Also new files created via rewritefs will be owned by the user that runs it, if you run it as root then all new files in your home directory will be owned by root and that would cause problems.

As for your issue of not being able access files owned by root via rewritefs, this shouldn't be a problem for a home directory as there isn't a need for files in your home directory to be owned by root in the first place.

[knezi]

No, I know how this work and I have changed all the regexps to ^knezi. Problem is that I have files in ~knezi owned by root.

[sloonz]

I want to just ask about permissions. I run it as regular user, but than I cannot operate with files owned by root. Is this intented behaviour?

Yes it is : FUSE applications like rewritefs does not run as setuid root, which means that they have the permissions of the user that run them. If you can’t access a file from a user and run rewritefs from this user, rewritefs won’t have access to that file.

IOW: il you ls a file in a rewritefs filesystem, the permissions to access the file will be the permissions of the rewritefs process, not the ls process.

Should it be run as root?

It should be able to be run as root, but root is not required, unless you want to be able to access through rewritefs to files accessible only by root.

The big problem in running rewritefs as root is that since I don’t use it that way, you may run into bugs that I didn’t have the chance to encounter ;)

Also new files created via rewritefs will be owned by the user that runs it, if you run it as root then all new files in your home directory will be owned by root

Yeah, that’s typically the sort of bug that I didn’t have the chance to encounter :)

I’ll try to land a fix for that one during next week.

@jdunn0 Thanks for your helpful comments, it is appreciated ;)

[knezi]

Thank you for your answers.

IOW: il you ls a file in a rewritefs filesystem, the permissions to access the file will be the permissions of the rewritefs process, not the ls process.

I haven't expressed correctly myself. This is what I was asking about. I have tried sudo cat root_owned_file, but still permission denied. It would be nice if the permission of the proccess cat would be preserved.

[sloonz]

Can you test the change-uid branch ? It will install rewritefs with the set-uid flag, with some modifications to handle owner on file creation.

[knezi]

Sure,
tomorrow or on thursday will let you know.

[knezi]

It works. I run rewritefs as root and tested: chown, chmod - it all works. Root can access anything and other users have the right access according to particular file permission.
Thanks for the great commit!
Will you push this to the upstream or should I manually change the branch?

[sloonz]

I’ll run with this branch a couple days to see if no issue arise, and then merge it to master

[knezi]

Ok. Thanks!

[sloonz]

Merged in master

[psycha0s]

I have a segmentation fault with XCOM2 game from steam when rewritefs is mounted by root (/etc/fstab). Will test it again by mounting from a non-root user.

[sloonz]

Can you open another issue for this ? Is this a regression of 3ac0d17 or you just tested this for the first time ?

[psycha0s]

I'm searching for a way to remove unwanted files from my home directory and just tested rewritefs for the first time. Currently, I'm working on a kernel module to achieve a similar result (I need just plain path replace without regular expressions). So I can't tell whether it's a regression or not. Just wanted to let you know my experience.