Writing To A Symlink On A Read-only File System That Land On A Read-write File System

Home » CentOS » Writing To A Symlink On A Read-only File System That Land On A Read-write File System
CentOS 5 Comments

We’ve come across a problem with 6.4 kernels that we didn’t have with
6.2 kernels – which involves writing to a symlink that is on a read-only file system – but the symlink lands on a read-write file system

The following shows the issue:

mkdir -p /mnt/tmp
mount -t tmpfs -o size=1% none /mnt/tmp
rm -f /tmp/file
ln -s /tmp/file /mnt/tmp/file
mount -o remount,ro /mnt/tmp
echo “some text” > /mnt/tmp/file

On a machine with a 6.2 kernel, the above works fine – the target of the symlink (/tmp/file) is created etc. with no error

But on a machine with a 6.4 kernel, the above fails with:

/mnt/tmp/file: Read-only file system.

Strace’ing a process that fails gives:

open(“/mnt/tmp/file”, O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EROFS
(Read-only file system)

I don’t have a machine with a 6.3 kernel, so I’m not sure when the change in behaviour happened, but does anyone know as to why this change was made in the kernel?

I’ve had a look through the kernel changelog – and the following entry mentions EROFS and read-only file systems:

– [fs] vfs: prefer EEXIST to EROFS when creating on an RO filesystem
(Eric Sandeen) [878091]

I can’t access that BZ (878091) entry – so don’t know if the above is anything to do with what I’m seeing …

Thanks

James Pearson

5 thoughts on - Writing To A Symlink On A Read-only File System That Land On A Read-write File System

  • This sounds like it’s going to be a glibc issue rather than a kernel issue; IIRC, it’s glibc that’s responsible for handling symlink processing, not the kernel.

    I wonder what happens if you, e.g. a statically-linked busybox from 6.2
    on the 6.4 machine.

    (As for whether or not it’s a bug…that’s an interesting question. Having symlinks crossing r/w< ->r/o boundaries is an odd case. I don’t know what symlink semantics technically supposed to be in those circumstances.)

  • Michael Mol wrote:

    It fails on a 6.2 install running a 6.4 kernel (i.e. the same glibc)

    I agree – I’m not sure what the ‘correct’ behaviour should be – it is just that what we are doing used to work – but no longer does

    I guess I’m trying to find out if this change is to correct the behaviour as it is really a ‘bug’ – or has happened inadvertently as a result of a fix for something else … i.e. if I need to submit this issue as a new bug

    Thanks

    James Pearson

  • James Pearson wrote:

    That’s weird, all right… but I would *never* have tried that, because I
    assume that ro mean READ ONLY. IMO, if you could write *anything* to a read-only filesystem, that was a serious bug, both in design and in security (gee, what a *great* way to get malware where it shouldn’t be!).

    mark

  • James Pearson wrote:

    Looks like this is known bug with 6.4 – and hopefully should be fixed in some later ‘zstream’ release

    James Pearson

LEAVE A COMMENT