[Samba] mount.cifs -> Unisys MCP Mainframe -- Linux touch command "setting times of `testfile.txt': Permission denied"

[Tim Lank]

On Wed, Aug 31, 2011 at 3:41 PM, Jeff Layton <jlayton at redhat.com> wrote:

> On Wed, 31 Aug 2011 14:55:26 -0400
> Tim Lank <timlank at timlank.com> wrote:
>
> > the mount.cifs is from (cifs-utils-4.8.1-2.el6.x86_64)
> >
> >
> > On Tue, Aug 30, 2011 at 8:05 PM, Tim Lank <timlank at timlank.com> wrote:
> >
> > > I've got a share from a Unisys MCP Mainframe mounted with mount.cifs
> from
> > > RHEL 6.1 (samba-common-3.5.6-86.el6.x86_64).
> > >
> > > when I try to touch a file, it creates the file, but reports an error -
> > > "setting times of `testfile.txt': Permission denied"
> > >
> > > strace on the touch command shows that it is erroring out on the
> > > utimensat() call
> > >
> > > utimensat(0, NULL, NULL, 0) = -1 EACCES (Permission denied)
> > >
> > > Documentation from the Unisys Mainframe can be found here....
> > >
> > >
> http://public.support.unisys.com/aseries/docs/clearpath-mcp-12.0/pdf/70118328-103.pdf
> > > Pages:  C-2 and C3 show what POSIX functions are/not supported
> > > utime() and utimensat() are not among the supported functions listed
> there.
> > >
> > >
> > > Is there any combination of parameters to mount.cifs that can be used
> that
> > > would prevent touch from reporting this error?
> > >
> > >
> > >
>
> (cc'ing linux-cifs ml)
>
> Most likely, this is a local (unix) permissions issue. CIFS has a rather
> unintuitive permissions model. It attempts to enforce permissions
> locally, but doesn't really have enough information to do so properly.
> This leads to these sorts of problems.
>
> When you create files as a particular user, then they end up being
> owned by the "default" file owner on the mount rather than the user
> that just created the file. Then when you go to set the time, the
> kernel tries to enforce the permissions on the file and denies you
> access to do so. This varies somewhat depending on whether CIFS posix
> extensions are in force, but it's a common problem.
>
> The best scheme is to switch the mount to being multiuser, but that
> requires a kerberized setup at the moment.
>
> Another workaround is to mount with '-o noperm' which disables local
> permissions checking entirely. This will however allow any process on
> the box to read and write to the server using the mount credentials.
>
> Another idea is to get creative with the uid=,gid=,file_mode=, and
> dir_mode= options. See the mount.cifs manpage. If you're careful, you
> can craft a set of options that will allow the users you want to have
> proper access without opening everything up.
>
> My SambaXP talk from last year covers a lot of this in detail if you're
> interested....
>
>    http://sambaxp.org/index.php?id=38
>
> Good luck!
> --
> Jeff Layton <jlayton at redhat.com>
>

Jeff,

Thanks for all the info.

A wireshark analysis shows that the Mainframe here is returning a frame that
shows that the file is created and granted exclusive open for writing.  The
file actually gets created on the Mainframe (presumably because of the
combination of my uid=,gid=,file_mode=, and
dir_mode= options) and I can modify it from all users on the mount.cifs
box.  The next request is from the mount.cifs box to modify "Created, Last
Access, Last Write, and Change" timestamp attributes for the (already)
opened file.  The response frame from the Mainframe is a basic "Access
Denied" message which I suppose the touch command turns into a "setting
times of" ... Permission Denied message being returned.

I'd like to try and get a kerberized setup going with mount.cifs.  I see the
sec=krb5 option, but is there a series of other config steps that I need to
perform (modifying /etc/krb5.conf for example).  Supposedly the Mainframe
already has kerberos mapping setup for all the users on our mount.cifs
system.

Any references (besides the mount.cifs manpage) that you can provide that
walk through the kerberized setup would be appreciated.

Thanks,
Tim