linux-kernel - Re: [PATCH] Add "-e" option to rpc.gssd to allow error on ticket expiry. Try 2 with added man pages.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1321655886.10541.24.camel@lade.trondhjem.org>
Date:	Sat, 19 Nov 2011 00:38:06 +0200
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	John Hughes <john@...vaedi.com>
Cc:	John Hughes <john@...va.com>, linux-nfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add "-e" option to rpc.gssd to allow error on ticket
 expiry. Try 2 with added man pages.

On Fri, 2011-11-18 at 23:08 +0100, John Hughes wrote: 
> On 11/18/2011 09:33 PM, Trond Myklebust wrote:
> > On Fri, 2011-11-18 at 20:19 +0100, John Hughes wrote:
> >    
> >> On 11/18/2011 07:35 PM, Trond Myklebust wrote:
> >>      
> >>>
> >>> You need a big fat warning somewhere that enabling this option WILL
> >>> cause data corruption...
> >>>
> >>>        
> >> Why?
> >>
> >> Because some process may get the EACCES error half way through it's
> >> operation.
> >>      
> > No. Because the process can receive a reply to the write() syscall that
> > indicates that the data is safe,
> 
> There is no reply from "write(2)" that says the data is safe.

Read the rest of the thread... Jim and Nick already made this point, and
I've replied.

The fact of the matter is that most application writers remain blithely
oblivious of the need to fsync() as the ext4 people know all to well:
see the attempts to impose the fully posix-compatible 'data=writeback'
mode as the default and the catastrophe that occurred when
'data=ordered' semantics changed for the rename() syscall. Adding new
failure modes needs to be done with care, or GNOME will crash and/or
your word processor _will_ lose your last hour or so of work.

> >   but the EKEYEXPIRED error will cause
> > the data to be lost when the client tries to actually commit the data to
> > disk.
> >
> >    
> >> The traditional Kerberos/AFS way was to behave the old way, and use
> >> krenew to keep the ticket from expiring if a process needed to be run
> >> overnight.
> >>      
> > Which is just wrong: the general intention of kerberos security is to
> > ensure that the _user_ has ACKed an operation. Renewing tickets without
> > user input would circumvent that intention. If you need to have the job
> > run overnight, then ask for a longer lifetime for your ticket.
> >    
> 
> Ok, so no need for the hang on ticket expired then.
> 
> (Although I don't think renewable tickets and krenew are a figment of my 
> imagination).

They are a workaround to the problem of users failing to plan ahead
and/or jobs not running as quickly as originally scheduled. You can run
them if you feel safe doing so, but they should not be a mandatory
feature to ensure data isn't lost during normal operation.

BTW: instead of trying to change existing kernel and gssd semantics, why
not concentrate on adding the equivalent of krenewd/kstart?

> >> What other way is there of fixing the problem if we are going to keep
> >> the "hang 'till a ticket turns up" behaviour?  (rewrite gnome and kde
> >> seems kind of a big job).
> >>      
> > Notify the kernel that a ticket is about to expire so that the kernel
> > can decide to block the process on the next NFS-related syscall.
> >
> >    
> I don't understand.  How is it a win to block processes *before* the 
> ticket has expired?

So that the kernel can flush out any dirty data while the ticket is
valid, and block further asynchronous read/write operations (either by
making them synchronous, or by returning an appropriate error). We may
also want to consider closing open file state and possibly freeing up
locks so that other processes with valid credentials may still access
the data.

IOW: that allows for an _orderly_ failure mode instead of the current
catastrophic mode. The application gets a chance to deal with any errors
_before_ the data is lost.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/