Bug 15875

Set CONFIG_EXT2_FS_POSIX_ACL to `n'?

Doesn't that require kernel recompilation? Besides we still need rwx ugo permissions for local filesystems.

Or maybe I didn't formulate the bug description correctly ;)

Again, I want a 'mount' option which disables usual UNIX permissions which are RWX UGO (and, of course, UID/GID).

ext2 supports `mount -o noacl'.

It doesn't work:

# dd if=/dev/zero of=ext2.img bs=100M count=1
...
# mke2fs ext2.img -> y
...
# mount -o loop,noacl ext2.img loop
# mount | grep noacl
/dev/loop0 on /tmp/loop type ext2 (rw,noacl)

$ cd /tmp/loop
$ touch test
touch: cannot touch `test': Permission denied

Probably it's worth implementing a more generous solution for all FS's on VFS level, i.e. something like:

man mount:

FILESYSTEM INDEPENDENT MOUNT OPTIONS
       Some of these options are only useful when they appear in the /etc/fstab file.

       Some of these options could be enabled or disabled by default in the system kernel. To check the current setting see  the  options  in
       /proc/mounts.

       The  following  options  apply to any filesystem that is being mounted (but not every filesystem actually honors them - e.g., the sync
       option today has effect only for ext2, ext3, fat, vfat and ufs):

***
       asroot  Map all uids and gids to the root user. It's useful
       for mounting removable storage  media.  Note that all files
       and directories created in this mode will be owned by root.

***

This would be "uid=", "gid=" options VFAT-style.

Whatever fits you, however don't forget that there are immutable and appendable only flags for ext2/3/4 and they should probably dismissed too.

I cannot change the assignee field of this bug report:

"You tried to change the Assignee field from fs_ext2@kernel-bugs.osdl.org  to fs_vfs@kernel-bugs.osdl.org  , but only the assignee of the bug, or a user with the required permissions may change that field."

Created attachment 27012 [details]
Tentative patch

Probably it's not difficult to write an implementation, but I have no idea how to check mount flags in namei.c inode_permission() function.

I've received an e-mail from some guy, it seems like he/she doesn't want or cannot use bugzilla, so I'm citing it as is:

> Dear Mr.Tashkinov:
> 
> Sorry for contacting you this way.
> 
> I would find it very useful if the flag of enabling or disabling the 
> permissions was written in the hard drive at format time.
> 
> I hope you find useful the suggestion.
> 
> Yours faithfully,
> 
> Guy name

(I'm not disclosing his/her name because probably he/she wants to remain anonymous).

But to my mind his/her suggestion cries for a new bug report.

So this bug report is highly confused.  Reading the original request, I think what the original poster was requesting was actually a way of disabling all access controls, and ACL's (meaning Access Control Lists) has nothing to do with this at all.

Ideally I think this should be a VFS-level mount option (like read-only, noatime) so that it's not an ext4 specific option.  But if we can't get consensus across other file system developer teams, doing it as an ext4 specific mount option is a possibility.

Yes, Theodore, you are quite right.

At first I wanted this option to be available only for ext{2,3,4} filesystems, but then I realized it's good to have it on a VFS level (some people may actually use any other FS on their removable mass storage devices).

And since this bug doesn't progress anywhere can you raise this question on LKML? After all you are a core kernel developer, so people will likely listen to your proposition more attentively.

Excuse me for my bad English :-)

Now we have many variants that can be implemented.

1. Disable rights control at VFS level or at formatting time. 
a) at VFS level only (FS-independent)
b) at formatting time only (FS-dependent)
c) both at VFS level and at formatting time (FS level). Default option is "rights on". It can be overwritted at FS level during formatting and then it can be overwritted at VFS level during mounting.

My vote is 1c.

2. In case of VFS-level option - what UID, GID and mode will be set for created files and directories?
a) as always. Independ of option "Disable rights control".
b) user root, group root, rwxrwxrwx.
c) something like umask option will be implemented.

In other words, we mount FS with disabling rights. Then we write something on it. Then we remount FS with enabling rights. What permissions will we see?

My vote is 2a.

3. Lets imagine that we have ext3 filesistem mounted with "Disable right control" option enabled. We run ls -l - what permissions will it show?
a) rwxrwxrwx
b) rwArwArwA, where A = true when at least one of "executable" bits on disk is set to "true".

In other words, will our new option affect all rights or only read-write but not exec?   

My vote is 3a (simple solution).

as such an option is needed to create a shared directory. now it uses bindfs: http://ubuntuforums.org/showthread.php?t=1460472, but it looks ugly.

Reply-To: cslee-list@cybericom.co.uk

On 04/11/10 15:48, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=15875
>
>
> Theodore Tso<tytso@mit.edu>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |tytso@mit.edu
>
>
>
>
> --- Comment #11 from Theodore Tso<tytso@mit.edu>   2010-11-04 15:48:22 ---
> So this bug report is highly confused.  Reading the original request, I think
> what the original poster was requesting was actually a way of disabling all
> access controls, and ACL's (meaning Access Control Lists) has nothing to do
> with this at all.
>
> Ideally I think this should be a VFS-level mount option (like read-only,
> noatime) so that it's not an ext4 specific option.  But if we can't get
> consensus across other file system developer teams, doing it as an ext4
> specific mount option is a possibility.
>
I know this is an old post I am dragging up but I have not seen any further 
discussion and I would like to see the a solution for the following use case:
I grab the SD card out of a friends camera which stores images on an extX file 
system and shove it into my PC. My PC makes all the files owned by me so that I 
can access them, just like today with FAT based sd cards.
If this is done at the VFS level then how is my PC going to know that the file 
system on the SD card has permissions that should be ignored?
Or should things like cameras all just write files with owner id 0 and 
permissions set to 777?
My issue with this is when I change the permissions by using some broken 
software and then put it back in the camera will it be able to store the images 
in a permission modified directory? or will the owner of the camera have 
problems later on when they try to get the content off the card?

It would be nice if the file system had a "data in this file system is for 
anyone who can get their hands on it" mode that was well defined so that device 
manufacturers would feel safer using it for mass end user use.

Regards,
Chris.

> Reply-To: cslee-list@cybericom.co.uk

It's unfeasible to add such a feature for every file system Linux supports, because some of them are not actively maintained.

Most likely it should be done in the VFS layer, unfortunately no one has stepped up for this task.(In reply to comment #15)

> Reply-To: Comment #15 from anonymous

> If this is done at the VFS level then how is my PC going to know that the
> file system on the SD card has permissions that should be ignored?

Let's imagine that "disable rights" option was implemented at VFS level.
PC can know that the file system on the SD card has permissions that should be ignored:
1) from fstab. We can add device ID (from /dev/disk/by-id) to fstab. It is not good to add any SD card to fstab.
2) from "removable" block device property. PC can mount all removable devices with this "disable rights" option. I am not sure that this solution is good in all possible situations. 

> Or should things like cameras all just write files with owner id 0 and 
permissions set to 777?

I think that cameras should do it always, independently of "rights disable" features.

> My issue with this is when I change the permissions by using some broken 
software and then put it back in the camera will it be able to store the images 
in a permission modified directory?

I think that camera must ignore permissions always. This requirement can be a problem if camera will be based on Linux kernel that has no any "disable rights" features.

> Reply-To: Comment #16 From Artem S. Tashkinov

> It's unfeasible to add such a feature for every file system Linux supports,
because some of them are not actively maintained.

But it is possible to add such feature to actively maintained file systems.
I think that this is not big error in assumption that actively maintained systems is actively used systems :-)

So, we need VFS-level option because we can't implement option in all file systems. And we need FS-level option because it will be much more comfortable in many cases.

Oops, excuse me for bad formatting :-)

;( very unfortunate.

It's not obsolete, Alan.

It's more than actual.

It's a feature request not a bug, and it's never going to be acted upon here.

There's no entity behind the kernel, so I cannot ask this "company" to deal with this feature request. RedHat has its own narrow corporate interests (and Linux on the desktop isn't their concern AFAICS), Ubuntu does what they deem necessary and that leaves us with what? OSDL? They are more a committee than a real company.

Please don't tell me about LKML - thousands of messages posted to LKML, asking for new features, remain unanswered. Even bug reports often get zero attention. LKML is not exactly a place to discuss feature requests - it's never been. It's a lazy discussion club where people choose to participate only if they are really interested in the questions being discussed. I don't even want to talk about timezone issues, vacations, leaves, etc. where messages are never read since responsible people ... have skipped or never noticed the messages addressed to them. How is it even professional? What's the point of LKML then? So, again, please don't tell me about LKML.

So, if you know a surefire way to e-mail the exact people who are responsible for VFS, please do me a favor and post their e-mail addresses here. I'm perfectly aware of the linux/MAINTAINERS file and also I perfectly know that people on that list, more often than not, never reply to e-mail messages in regard to the things thousands of people are absolutely interested in.

I perfectly know that just a few hours are required in order to implement this particular feature, yet you choose to close bugs without letting people know how to deal with this situation.

Last but not least, and mark my word, I will keep reopening this bug until  "Importance: 	Enhancement " exists in this bugzilla.

If you don't want to see feature requests here, remove this option. Of course this decision will mark another setback in the kernel development but who cares? You definitely don't, and as a leading kernel developer you definitely show what your preferences are.

LKML is not for new feature requests either. It's for *patches*

If you want a feature, then write it or pay someone to write it. It's 'Free Software' not 'Charity'.

You can keep re-opening the bug if it amuses you but nobody else actually cares so you are just wasting everyones time.


Alan

I remember Linus has publicly expressed his discontent (https://www.youtube.com/watch?v=jjRAKuis7T8#t=979) about the state of Linux on the desktop at least ten times already.

With this:

> If you want a feature, then write it or pay someone to write it. It's 'Free
> Software' not 'Charity'.

no wonder Linux is not going to be on the desktop ever (2% of the populace mainly comprised of geeks don't count). You see, basic features like being able to effortlessly move your files between different PCs do not work on Linux properly. Bravo!

So according to your words in order to run Linux I have to become a programmer? Are you serious?

BTW as far as I have noticed bugzilla.kernel.org is not for discussing bugs either - there are just too many bugs closed as abandoned. And LKML is only for patches. What a nice world of Linux! Your opinion just will not be heard.

And last but not least, how am I supposed to find the people who will implement this feature? What are the chances the patch will be actually merged and maintained? What if one day you wake up feeling bad, sad or dissatisfied and you decide let's drop it? Does that mean my money will be totally wasted?

Besides what if someone's ego or unspoken policy will not allow a merger?

So to summarize your post - the Linux kernel is meant only for kernel developers. Features or bug reports, that are of no interest for you, do not matter and will not be taken care of. Yeah, for instance, you refuse to merge BFS and other Con's patches without any sound reasons - for instance BFS may exist as a configurable _non-default_ option, yet ... no, we won't merge it. So there's no guarantee whatsoever that the patch for this feature request will be merged - in short your statement about "write it" does not make sense - I can also fart and make the same impact.

Please, remove "Enhancement" from the list of possible options please. I insist.

This bug report CC's fs_vfs@kernel-bugs.osdl.org yet I see no people actively proposing to implement this feature for money.

How come? Is fs_vfs@kernel-bugs.osdl.org yet another dead mailing list?

As relevant as ever.

This is not a feature tracker

You can re-open it every few years if you want but nothing will ever happen here. If you want something to happen discuss it on the mailing lists, and provide patches and use cases.

See my comments in 2013.

... came across this "bug" report today by accident and here are my 2¢: 

I've developed a kernel-patch (ugly, proof of concept) some years ago (for kernel 3.2). It adds a mount option to the ext4-kernel-driver to disable rights enforcement (so it can be turned on and off, on demand). Result: any ext4 media can be used as a shared medium between non-root-users like with fat or ntfs media (within linux). 

Ready for automounting (enabled via default mount option in filesystem header). Compatibility with all non-patched linux systems is preserved - no change in filesystem layout.

I've wrote to the lkml, didn't get any answer. Get a more detailed feature-description and patch there:
http://lkml.iu.edu/hypermail/linux/kernel/1209.3/02878.html

Drawback: it's implemented in ext4-layer and not vfs-layer and I'm not a kernel hacker - not even an experienced coder - so you will probably beat me round my head with it... ;-)

Thank you! but

> Drawback: it's implemented in ext4-layer

just doesn't cut it.

People need a general solution for all Linux file systems (some crazy guys use pretty exotic filesystems), i.e. something for VFS. That's why this patch was ignored - it's more like a hack.

This hack works and it's usable with the far most common linux filesystem. It's a solution for your challange: "So, I strongly suggest implementing a flag which tells the kernel to disregard all file/directory permissions on the aforementioned FS's." (with ext2/ext3/ext4, usable by the ext4-kernel-driver)

But you're right, vfs is the better place not only because of a general filesystem-independent solution. The ext4-layer doesn't know of the currently active desktop user so either the rights management is enforced or _everyone_ is allowed to read/write. That's the real ugly part of it. That's the reason I do not like the patch either. Better thing would be to use the mount manager to tell the vfs to only allow _the_ one foreground user to do things but disallow every other processes - like mapping the foreground user to root for one special device (usb disk or flash drive or ...).

Btw: People need a general solution, you're right. So this working solution for ext4 is undesirable. With the effect that people are still forced to use fat and ntfs where things work like expected (Alice can read Peters work) - that's a far more general solution and it's even more platform independend. Fat and ntfs are usable not only from Linux but also Windows, the most common desktop platform, where there's no common xfs/ext4/btrfs/... driver. So yes, you're right, using fat or ntfs _is_ the more general solution. :-P