2014/1/20 One Thousand Gnomes gnomes@lxorguk.ukuu.org.uk:
Shouldn't this also check for CAP_SYS_DAC or some similar permission so that root can override such a mess (eg to fix full disks in an emergency) ?
May be it's better to let root an ability to remount the system without sharelock mount option and then fix an emergency?
Doesn't that involve breaking the service for all users of the system relying upon those locks, while root being allowed to ignore the locks does not ?
If we allow root to remount without "sharelock" (or bypass conflict checks), it will definitely break the service for all users. Probably it's better to stop the service (that cause all sharelocks to be unlocked), fix the emergency and start the service again.
In the current state, the patchset doesn't allow any sort of ignoring those locks for mounts with "sharelock" option (either remount without "sharelock" or set special capabilities). It was done to make sure nothing breaks applications relying upon sharelock behavior. Also, that's why "sharelock" mount option was added: this behavior is dangerous to be on critical system paths like "/" or "/lib" and not suitable for global use.