On Wed, Jan 30, 2019 at 07:35:39AM -0600, Eric W. Biederman wrote:
> I suspect that as long as userspace supports /etc/fstab and we in turn
> support /proc/mounts there is going to be a lot of pressure to keep
> the majority of options so they can be encoded in a string separated by
> commas.
Wel
On Wed, Jan 30, 2019 at 01:01:54PM +, David Howells wrote:
> Karel Zak wrote:
>
> > It seems more elegant is to ask for Nth option as expected by fsinfo().
>
> More elegant yes, but there's an issue with atomiticity[*]. I'm in the
> process of switching to something that returns you a singl
On 1/30/2019 4:47 AM, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>>> Casey Schaufler writes:
Are you taking the LSM specific mount options into account?
>>> In the design yes, and I allow setting them.
Karel Zak writes:
> On Tue, Jan 29, 2019 at 03:44:22PM -0600, Eric W. Biederman wrote:
>> so I am proposing we change this in the new mount api.
>
> Well, this forces me to ask what the new API is? :-)
>
> It seems that David uses fsconfig() and fsinfo() to set and get
> mount options, and your p
David Howells writes:
> Karel Zak wrote:
>
>> It seems more elegant is to ask for Nth option as expected by fsinfo().
>
> More elegant yes, but there's an issue with atomiticity[*]. I'm in the
> process of switching to something that returns you a single buffer with all
> the options in, but ea
David Howells writes:
> You need to rebase on linus/master. A bunch of your patches are obsoleted by
> Al's security changes there.
Before anything is merged definitely.
Al dealt with mount options from the LSMs in a slightly different way
than I did. At a practical level Als version of the c
Karel Zak wrote:
> It seems more elegant is to ask for Nth option as expected by fsinfo().
More elegant yes, but there's an issue with atomiticity[*]. I'm in the
process of switching to something that returns you a single buffer with all
the options in, but each key and each value is preceded b
You need to rebase on linus/master. A bunch of your patches are obsoleted by
Al's security changes there.
David
ebied...@xmission.com (Eric W. Biederman) writes:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Casey Schaufler writes:
>>> Are you taking the LSM specific mount options into account?
>>
>> In the design yes, and I allow setting them. It appears in the code
>> to retrieve the mount op
On Tue, Jan 29, 2019 at 03:44:22PM -0600, Eric W. Biederman wrote:
> so I am proposing we change this in the new mount api.
Well, this forces me to ask what the new API is? :-)
It seems that David uses fsconfig() and fsinfo() to set and get
mount options, and your patch introduces fsset() and fso
ebied...@xmission.com (Eric W. Biederman) writes:
> Casey Schaufler writes:
>> Are you taking the LSM specific mount options into account?
>
> In the design yes, and I allow setting them. It appears in the code
> to retrieve the mount options I forgot to call security_sb_show_options.
>
> For fi
Casey Schaufler writes:
> On 1/29/2019 1:44 PM, Eric W. Biederman wrote:
>> All,
>>
>> With the existing mount API it is possible to mount a filesystem
>> like:
>>
>> mount -t ext4 /dev/sda1 -o user_xattr /some/path
>> mount -t ext4 /dev/sda1 -o nouser_xattr /some/other/path
>>
>> And have both m
On 1/29/2019 1:44 PM, Eric W. Biederman wrote:
> All,
>
> With the existing mount API it is possible to mount a filesystem
> like:
>
> mount -t ext4 /dev/sda1 -o user_xattr /some/path
> mount -t ext4 /dev/sda1 -o nouser_xattr /some/other/path
>
> And have both mount commands succeed and have two mo
All,
With the existing mount API it is possible to mount a filesystem
like:
mount -t ext4 /dev/sda1 -o user_xattr /some/path
mount -t ext4 /dev/sda1 -o nouser_xattr /some/other/path
And have both mount commands succeed and have two mounts of the same
filesystem. If the mounter is not attentive
14 matches
Mail list logo
