12

Is it possible to disable file permissions on an ext3/4 file-system?

Just wondering if it's possible to completely disable or ignore file permissions on a ext3 or ext4 file system. Perhaps a mounting option?

I'm not concerned about the security implications as I would be doing this for testing and with removable media.

Corey
  • 555
  • 3
  • 6
  • 15
  • 2
    Why would you want to remove file permissions from an ext3 or ext4 filesystem? They were built with POSIX file permissions in mind. If you are looking to use a filesystem with limited permissions options, perhaps something like FAT32 or exFAT would be better? – Rob Gibson Mar 06 '13 at 21:09
  • I'm curious if there is a Linux native option – Corey Mar 06 '13 at 21:10
  • 2
    It is a Linux-native option to use FAT32, as it is a supported filesystem. You simply need to use a filesystem which is not designed for POSIX systems, as those that are support file permissions. – Rob Gibson Mar 06 '13 at 21:35
  • 1
    wouldn't `$ sudo chmod -R 777 /your/filesystem` do the trick? – Red Cricket Mar 06 '13 at 21:47
  • 1
    @RedCricket that would be a workaround if the answer turns out to be no – Corey Mar 06 '13 at 23:52
  • possible duplicate of [Mounting an ext3 fs with user privledges](http://unix.stackexchange.com/questions/14671/mounting-an-ext3-fs-with-user-privledges) – Gilles 'SO- stop being evil' Mar 07 '13 at 21:44
  • A bit more fortunate question: http://unix.stackexchange.com/questions/126213/external-hard-drive-permissions-ext4 – Michael Shigorin Oct 12 '14 at 15:20
  • There is no such disabling option in any of the *nix flavors. The purpose for creating *nix was security, how could you supersede that. – AReddy Aug 31 '16 at 03:19

3 Answers3

6

That's not the only thing you can do.

There is a way to just grant everyone permissions without using the regular permissions, that will clutter your display (in a way).

What this means is that ls --color (by default) will always display o:rwX in a block background, which is hideous and only meant to alert users to wrong permissions (when they are right for you).

But you can easily achieve universal (or near-universal) write permissions to your files by using access control lists.

setfacl -d -m g:sudo:rwX .
setfacl -m g:sudo:rwX .

will give rwX permissions to all people in the sudo group. Since most of your systems, you will have a user in the sudo group, particularly for removable media (and hence, local systems) you will always have access anywhere for anyone in that group (which is you). You can also extend it to users, in case you are on some other system which uses that group:

setfacl -d -m g:users:rwX .
setfacl -m g:users:rwX .

The -d flag means that the permissions will propagate to all newly created files (default). The only downside is that you cannot actually normally see those permissions, which means you'd rather turn them off completely (hence, what is the use on a removal medium if you set permissions that everyone can circumvent anyway, right?). That's like saying: You can access these files if you call yourself John. Okay, I call myself John. Fine, you have access now.

(Everyone can assume root on every system they own and hence filesystem permissions mean nothing).

ExtFS is just not meant for removable media. There are no Linux filesystems that are really useful on removable media, but FAT and NTFS have the downside of not really supporting symlinks and execute flags, which is difficult for git repositories, for example. Just my opinion here.

You can only see your file ACL by doing:

getfacl <file>

And when you ls -l you will see:

drwxr-xr-x+ 4 user user 4096 aug 31 03:40 .

The + indicates that there is an ACL active on the file (or directory).

The output of getfacl will be (for example):

# file: .
# owner: user
# group: user
user::rwx
group::rwx                      #effective:r-x
group:sudo:rwx                  #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:sudo:rwx
default:mask::rwx
default:other::r-x

I don't know all the details, but this should work. As long as you are in sudo, you can do anything.

rustyx
  • 287
  • 1
  • 9
Xennex81
  • 161
  • 1
  • 2
  • 1
    Is there a way to do this *without* modifying the filesystem such as with a mount option? – Melab Aug 31 '20 at 19:53
5

No you can`t drop the file permissions for ext{2,3,4} file systems.

The only thing you can do is to set all files to 777 permission.

Just run:

 chmod a+rwX -R <mountpoint>
H.-Dirk Schmitt
  • 1,999
  • 11
  • 13
  • 5
    Better make that `chmod a+rwX -R ` to not give spurious execute permissions. – vonbrand Mar 07 '13 at 00:10
  • @vonbrand right – H.-Dirk Schmitt Mar 07 '13 at 00:12
  • but the `X` in `chmod a+rwX` makes all files executable, right? That's a good thing?? – a06e Aug 20 '15 at 17:24
  • 5
    @becko You've missed the point of the previous two comments. Upper-case `X` will only make directories executable (enterable) without making files executable; whereas lower-case `x` will makes all files and directories executable. – XA21X Nov 16 '15 at 08:45
0

Of course filesystem permissions are just checked by the filesystem driver (module) and if you were to patch that module, you could disable filesystem permissions all you want.

I once did this for cifs.ko, the 'Samba' (client) module for the kernel, because there are some samba bugs where you ought to have local access, and you have remote access, but still access is not granted.

I disabled local permission checking if the local user was in the (local) group of the file, the same thing as the "noperm" option, only activating when you are a group member, this time.

Of course, extfs is not exactly a module in the kernel, but a new flag would be trivial to add.

Xennex81
  • 161
  • 1
  • 2
  • I'm not sure if you're answering the question or not. You say it's possible, if it was a module, then you say that it's not a module. – Jeff Schaller May 14 '18 at 02:14
  • It would be possible if the sun danced square in the sky too. If you knew anything about the kernel, you'd know that something not being a module would require recompiling the entire kernel, which is a bit prohibitive for ordinary people, while compiling a module is relatively free. I merely voice the fact that there is nothing inherent about Linux which would preclude such an option from arising, because this limitation has bugged me a lot as well. – Xennex81 May 15 '18 at 06:40