CentOS - Apr 2013 - Writing to a symlink on a read-only file system that land on a read-write file system

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

On 04/22/2013 08:42 AM, James Pearson wrote:
> 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 ...
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.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20130422/922761c5/attachment.sig>

Michael Mol wrote:
> 
> 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.
It fails on a 6.2 install running a 6.4 kernel (i.e. the same glibc)
> (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.)
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:
> 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
<snip>
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:
> 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.
Looks like this is known bug with 6.4 - and hopefully should be fixed in 
some later 'zstream' release

James Pearson