Re: [PATCH 0/3] cifs: some random patches for 2.6.31

On Tue, 26 May 2009 12:28:56 -0500
Steve French <[email protected]> wrote:

> On Tue, May 26, 2009 at 11:42 AM, Jeff Layton <[email protected]> wrote:
> > On Tue, 26 May 2009 10:08:27 -0500
> > default, but 0744 (or 0755 even) would be an improvement. VFAT seems to
> > default to 0755, so maybe we should just go with that.
> 
> No problem at all using the 0755 default, unless other users object it
> seems better than current default
> 

Ok, I'll respin and resend once we get some of these other patches
settled.

> >> 3) No problem will merge very soon
> > Let me turn this question around. Why should /bin/mount bother
> > restricting user mounts to those entries in /etc/fstab if you can
> > easily circumvent those restrictions by calling the setuid mount helper
> > directly?
> 
> If mount.cifs only supports user mounts through fstab, then
> you couldn't bypass this behavior by calling mount.cifs directly - it
> would still look for a matching entry in fstab.
> You added code to mount.cifs to check fstab ... right?
> I thought that you were suggesting
> a) turning mount.cifs to setuid by default

No, that would be up to the distros. I think most would ship it
non-setuid by default. We know however that people do make it setuid on
their own, so I just want to ensure that mount.cifs plays by the rules
for mount helpers when someone does this.

> b) forbidding all user mounts via mount.cifs unless they were explicitly
> permitted via fstab

That's exactly what I'm proposing. It's the way /bin/mount (and by
extension, mount helpers) are supposed to work.

> (I was simply suggesting that we make sure
> that the syntax of fstab cifs mounts is broad enough to support
> both use cases.

That's my question. I don't see a way to make mount.cifs follow the
rules for mount helpers and yet still allow it to do what it does today
when made setuid -- let someone mount a cifs filesystem on any directory
that they own. These goals seem mutually exclusive to me. Can you
outline what you have in mind?

-- 
Jeff Layton <[email protected]>