Hi!
> > We had a user report at https://bugzilla.redhat.com/show_bug.cgi?id=449080
> > that in 2.6.25, he can no longer rsync to a vfat partition, even as root.
> > I just reproduced this here. It gets -EPERM in the mkstemp call.
> > (full strace in the bug report).
> >
> > Did we change behaviour somehow in the vfat code?
> > 2.6.24.7 works fine apparently.
>
> Yes, it was changed. New one allows only acceptable chmod(), and if not
> acceptable, it returns -EPERM. Old one allows even if it can't store the
> disk inode. But it may be too strict for users.
Hmm... but I guess mkstemp is no longer safe with this?
So we have choice between security hole and regression...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek <[email protected]> writes:
> Hi!
Hi,
>> > We had a user report at https://bugzilla.redhat.com/show_bug.cgi?id=449080
>> > that in 2.6.25, he can no longer rsync to a vfat partition, even as root.
>> > I just reproduced this here. It gets -EPERM in the mkstemp call.
>> > (full strace in the bug report).
>> >
>> > Did we change behaviour somehow in the vfat code?
>> > 2.6.24.7 works fine apparently.
>>
>> Yes, it was changed. New one allows only acceptable chmod(), and if not
>> acceptable, it returns -EPERM. Old one allows even if it can't store the
>> disk inode. But it may be too strict for users.
>
> Hmm... but I guess mkstemp is no longer safe with this?
>
> So we have choice between security hole and regression...?
Maybe. But if users choose the group or world writable umask, I guess
nobody would care the permission of temporary file, because all file is
writable always. Um..
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
> Maybe. But if users choose the group or world writable umask, I guess
^^^^^
umask mount option
> nobody would care the permission of temporary file, because all file is
> writable always. Um..
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
>>> > We had a user report at https://bugzilla.redhat.com/show_bug.cgi?id=449080
>>> > that in 2.6.25, he can no longer rsync to a vfat partition, even as root.
>>> > I just reproduced this here. It gets -EPERM in the mkstemp call.
>>> > (full strace in the bug report).
>>> >
>>> > Did we change behaviour somehow in the vfat code?
>>> > 2.6.24.7 works fine apparently.
>>>
>>> Yes, it was changed. New one allows only acceptable chmod(), and if not
>>> acceptable, it returns -EPERM. Old one allows even if it can't store the
>>> disk inode. But it may be too strict for users.
>>
>> Hmm... but I guess mkstemp is no longer safe with this?
>>
>> So we have choice between security hole and regression...?
>
> Maybe. But if users choose the group or world writable umask, I guess
> nobody would care the permission of temporary file, because all file is
> writable always. Um..
BTW, if users specified "quiet" option, FAT driver will ignore some
permission check (uid, gid, etc.).
So, another solution would be to specify this option, or change default
of it.
--
OGAWA Hirofumi <[email protected]>
OGAWA Hirofumi <[email protected]> writes:
> BTW, if users specified "quiet" option, FAT driver will ignore some
> permission check (uid, gid, etc.).
And it will return 0 without changing attribute.
> So, another solution would be to specify this option, or change default
> of it.
--
OGAWA Hirofumi <[email protected]>
On Mon 2008-06-02 06:12:23, OGAWA Hirofumi wrote:
> Pavel Machek <[email protected]> writes:
>
> > Hi!
>
> Hi,
>
> >> > We had a user report at https://bugzilla.redhat.com/show_bug.cgi?id=449080
> >> > that in 2.6.25, he can no longer rsync to a vfat partition, even as root.
> >> > I just reproduced this here. It gets -EPERM in the mkstemp call.
> >> > (full strace in the bug report).
> >> >
> >> > Did we change behaviour somehow in the vfat code?
> >> > 2.6.24.7 works fine apparently.
> >>
> >> Yes, it was changed. New one allows only acceptable chmod(), and if not
> >> acceptable, it returns -EPERM. Old one allows even if it can't store the
> >> disk inode. But it may be too strict for users.
> >
> > Hmm... but I guess mkstemp is no longer safe with this?
> >
> > So we have choice between security hole and regression...?
>
> Maybe. But if users choose the group or world writable umask, I guess
> nobody would care the permission of temporary file, because all file is
> writable always. Um..
Okay, if the user wants his vfat world-readable, it is hard to create
security hole there.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html