Home / server / Questions / 299406
Accepted
sciurus
Asked: 2011-08-10 13:25:50 +0800 CST

Security implications of filesystem ownership

  • 772

Does giving a non-root user ownership of a filesytem have any security implications?

For example, the directory /var/lib/pgsql/9.0/data and its contents needs to be owned by the postgres user. If I want to put its contents on its own filesystem, is it good practice to

  • mount that filesystem directly on /var/lib/pgsql/9.0/data

or

  • create a directory that is owned by root (such as /mnt/pgsql_data), mount the filesystem there, create a directory owned by postgres on that filesystem (such as /mnt/pgsql_data/data) and make /var/lib/pgsql/9.0/data a symlink to that directory

The only potential security problem I can see with the former is that it gives the postgres user the ability to alter the lost+found directory (if it is an ext2, ext3, or ext4 filesystem), but I don't think this has serious implications.

What motivated me to ask this question is that creating a postgres database isn't supported if a filesystem is mounted on the data directory; see this pgsql-hackers discussion. I hadn't considered the first point of that post before.

linux mount filesystems security

2 Answers

  1. I'm not aware of any real security implications. I think the key point is that linux mounts completely replace what's already there in the directory (well unless you're doing a union mount but that's a different subject).

    For simplicity and convention sake I would just make the data directory owned by root, and do the mount there.

    • 2
  2. Best Answer

    Depends on the file-system. As far as I know, ext3 for example will not recognise the uid of owner of the mountpoint but only the uid of the mounted partition root.

    In any case, imagine that you are using some lame file-system that will respect ownership and follow me...

    Depending on the file system hierarchy and contents there may be serious security implications.

    Let me exemplify (apologies for the degree of artistic freedom but I will not consider possible file locking issues... 8D )

    #mkdir /opt/postgres
#mount /dev/sdf1 /opt/postgres
#chown postgres:portgres /opt/postgres
#ls - /opt/postgres/8.3/
drwxr-xr-x 4 postgres postgres  1024 2011-08-11 23:14 .
drwxr-xr-x 7 root  root    48 2011-08-11 23:11 ..
drwxr-xr-x 2 root  root  1024 2011-08-11 23:14 bin
drwxr-xr-x 2 root  root  1024 2011-08-11 23:14 lib
drwxr-xr-x 2 root  root  1024 2011-08-11 23:14 doc
drwxr-xr-x 2 root  root  1024 2011-08-11 23:14 contrib
drwx------ 2 root  root 12288 2011-08-11 23:13 lost+found

    now suppose that someone has postgres access and wants to backdoor /opt/postgres/8.3/bin/createdb

    $cd /opt/postgres
$cp -R 8.3 .hackme
$cd .hackme/bin
$echo 'rm -rf /' > createdb
$cd ..
$mv 8.3 .old; mv .hackme 8.3

    This sort of privilege escalation attacks are sort of dated... Variants used to be reasonably common in the past. I must add this sort of faulty approach is one of the main reasons why standard recommendation is to have configuration files (e.g. httpd.conf) owned by user other than the one used by the process.

    Hope it helps

    • 0