Re: crash with aufs2 on 2.6.27.42

[Hans-Peter Jansen]

On Friday 05 February 2010, 04:52:34 sf...@users.sourceforge.net wrote:
> "Hans-Peter Jansen":
> > Feb  4 22:21:09 x130 postfix/postfix-script[6130]: starting the Postfix
> > mail system Feb  4 22:21:09 x130 postfix/master[6131]: fatal:
> > fifo_listen: fchmod public/pickup: Operation not permitted
> >
> > Here's the relevant trace.
> >
> > 7621  geteuid32()                       = 0
> > 7621  setresgid32(-1, 51, -1)           = 0
> > 7621  setgroups32(1, [51])              = 0
> > 7621  setresuid32(-1, 51, -1)           = 0
> > 7621  time(NULL)                        = 1265319834
> > 7621  send(3, "<22>Feb  4 22:43:54 postfix/master[7621]: set_eugid:
> > euid 51 egid 51", 68, MSG_NOSIGNAL) = 68 7621  unlink("public/pickup") 
> >          = 0
> > 7621  mknod("public/pickup", S_IFIFO|0622) = 0
> > 7621  open("public/pickup", O_RDWR|O_NONBLOCK) = 12
> > 7621  poll([{fd=12, events=POLLIN}], 1, 0) = 0 (Timeout)
> > 7621  fstat64(12, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
> > 7621  fchmod(12, 0622)                  = -1 EPERM (Operation not
> > permitted) 7621  time(NULL)                        = 1265319834
> > 7621  send(3, "<18>Feb  4 22:43:54 postfix/master[7621]:
> > fatal: fifo_listen: fchmod public/pickup: Operation not permitted",
> > 107, MSG_NOSIGNAL) = 107
> >
> > You mentioned in the thread, that NFS may also uses ->private_data.
> > Could this be the reason for this issue?
>
> I don't know.
> The case in last November was a problem in fchown of AppArmor, but yours
> is fchmod.
> The reason can be any of these.
> - AppArmor has a simler problem in fchmod.
>   According to Ubuntu Intrepid source files, fchmod doesn't have the
>   problem. But I am not sure whether linux/fs/open.c in openSUSE is the
>   same one in Intrepid. I have not read the source files of openSUSE
>   11.1.

I will check.

> - NFS server doesn't allow such operation.
>   Generally your NFS server needs to allow clients to access as
>   superuser.

No, the NFS setup is fine. I've written a tiny test program, that exercises 
this issue (attached):

Testing on /read-write (ordinary NFS3 mount, aufs / is based on):

5467  chdir("/read-write/var/spool/postfix") = 0
5467  setregid32(-1, 51)                = 0
5467  setgroups32(1, [51])              = 0
5467  setreuid32(-1, 51)                = 0
5467  unlink("public/pickup")           = 0
5467  mknod("public/pickup", S_IFIFO|0622) = 0
5467  open("public/pickup", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
5467  fchmod(3, 0622)                   = 0

And on the aufs /:

5465  chdir("/var/spool/postfix")       = 0
5465  setregid32(-1, 51)                = 0
5465  setgroups32(1, [51])              = 0
5465  setreuid32(-1, 51)                = 0
5465  unlink("public/pickup")           = 0
5465  mknod("public/pickup", S_IFIFO|0622) = 0
5465  open("public/pickup", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
5465  fchmod(3, 0622)                   = -1 EPERM (Operation not permitted)

(the write calls of the print statements were removed)

Thus, it sounds, like it's (1).

Oh well..

Thanks,
Pete

postfix-check.py
Description: application/python

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com