Bug 1072858 - Wrong value for expired grace period retrieved over network
Summary: Wrong value for expired grace period retrieved over network
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: quota   
(Show other bugs)
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Petr Pisar
QA Contact: Jan Ščotka
Milan Navratil
URL: https://sourceforge.net/p/linuxquota/...
Whiteboard:
Keywords: Patch
: 1067352 (view as bug list)
Depends On:
Blocks: 1313485 1110700 1191021 1289025 1295829
TreeView+ depends on / blocked
 
Reported: 2014-03-05 10:03 UTC by Petr Pisar
Modified: 2016-11-04 00:18 UTC (History)
5 users (show)

Fixed In Version: quota-4.01-13.el7
Doc Type: Bug Fix
Doc Text:
*quota* now correctly reports the grace time Previously, the integer type was misinterpreted if the *quota* tool displayed the grace time for an NFS-mounted file system if the soft quota limit for the current user was exceeded, and the grace quota time already expired. As a consequence, the "quota" command incorrectly reported a large number of days instead of the `none` value. This update fixes the misinterpretation of the integer type used to transfer grace times over the network. In addition, this update limits the range of possible values to 32-bit signed integer boundaries to ensure interoperability between NFS servers and clients with a different CPU word size. As a result, the *quota* tools correctly report grace time that differs from the server time in the range from -2^31+1 to 2^31 seconds. Lower values are reported as expired, and higher as a maximal possible time that stays unchanged until the difference is in the correct range.
Story Points: ---
Clone Of: 1066516
Environment:
Last Closed: 2016-11-04 00:18:21 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed fix (4.68 KB, patch)
2014-03-05 10:03 UTC, Petr Pisar
no flags Details | Diff
Upstream fix (4.81 KB, patch)
2016-03-04 07:35 UTC, Petr Pisar
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2195 normal SHIPPED_LIVE quota bug fix and enhancement update 2016-11-03 13:21:29 UTC

Description Petr Pisar 2014-03-05 10:03:07 UTC
+++ This bug was initially created as a clone of Bug #1066516 +++

Description of problem:

Trying to check the quota of a users from an nfs client, (the directory resists on an nfs filesystem), you get a huge value for grace period, instead of none.

Version-Release number of selected component (if applicable):
RedHat 6.4


How reproducible:
Always

Steps to Reproduce:
1. Set up an NFS server, with a local filesystem ext4, with quota enabled
2. Run quota -v  <username> on nfs server and you get the following output 
[root@server]# quota -v user1
Disk quotas for user user1 (uid 3059):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/mapper/HomeVG-StudentLV
                 178000  491520  501760            7771       0       0
/dev/mapper/MailVG-MailLV
                 254548* 244800  256000    none    1104       0       0

3. On an nfs client, that mount the above filesystem (with nfsv4 protocol)
if you issue the command 
quota -v user1, your get  a huge number for grace period instead of none

[root@nfsclient~]# quota -v user1
Disk quotas for user user1 (uid 3059):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
csfs9:/mail/
                 254548* 244800  256000 49703days    1104       0       0
csfs7:/home/students/
                 178000  491520  501760            7771       0       0

[...]
Additional info:
The same output can be verified on both redhat linux 5 and 6, with nfs protocol v3 and v4.
For users that their grace period has not been expired, you get the correct number of days.
The grace period has also been defined on nfs server.Running edquota -t  on nfs server you get the output below :

Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
  Filesystem             Block grace period     Inode grace period
  /dev/mapper/HomeVG-StudentLV                  7days                  7days
  /dev/mapper/MailVG-MailLV                  7days                  7days

[...]
--- Additional comment from Petr Pisar on 2014-02-20 10:12:31 GMT ---

I forwarded the problem the upstream, as all versions of quota tools are affected and there is no bullet-proof solution due to badly designed RPC protocol the quota tools use.

[...]
--- Additional comment from Petr Pisar on 2014-03-05 09:37:24 GMT ---

How to test:

(1) Create an file system with enabled quotas.
(2) Export the file system over NFS and mount the NFS file system.
(3) Set quota limits for a user. Use soft limit lower than hard limit.
(4) Create file large enough to exceed the soft limit.
(5) Set grace time to a slightly more than 60 seconds:
    $ setquota -u root -T 60 0 /mnt/quota/
(6) Verify 1 minute of grace time is reported by quota(1) tool on the server and
    on the client:
# quota
Disk quotas for user root (uid 0):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
     /dev/loop0      21*     20      40   00:01       3       0       0
127.0.0.1:/mnt/quota/
                     21*     20      40   00:01       3       0       0
(7) Wait until the grace time (60 seconds) expires.
(8) Verify that the grace time is reported as `none' on both server and client.
Before:
Disk quotas for user root (uid 0):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
     /dev/loop0      21*     20      40    none       3       0       0
127.0.0.1:/mnt/quota/
                     21*     20      40 49697days       3       0       0       
After:
# quota
Disk quotas for user root (uid 0):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
     /dev/loop0      21*     20      40    none       3       0       0
127.0.0.1:/mnt/quota/
                     21*     20      40    none       3       0       0

-------

RHEL-7 is affected

Comment 1 Petr Pisar 2014-03-05 10:03:51 UTC
Created attachment 870890 [details]
Proposed fix

Comment 2 Petr Pisar 2014-05-02 13:10:28 UTC
*** Bug 1067352 has been marked as a duplicate of this bug. ***

Comment 3 Petr Pisar 2014-05-02 13:11:46 UTC
Patch accepted by the upstream as:

commit d850a85b2374fe1b83779c0fc61463057eeca4ab
Author: Petr Písař <ppisar@redhat.com>
Date:   Mon Feb 24 15:54:32 2014 +0100

    Prevent from grace period overflow in RPC transport

Comment 4 M.T 2014-10-30 11:44:11 UTC
The same problem reported here,  exists also in RedHat ver7. Any updates for RH7?

Comment 7 Petr Pisar 2016-03-04 07:35 UTC
Created attachment 1133074 [details]
Upstream fix

Comment 9 Petr Pisar 2016-03-04 08:43:36 UTC
Testing instructions are at the end of comment #0.

Comment 13 errata-xmlrpc 2016-11-04 00:18:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2195.html


Note You need to log in before you can comment on or make changes to this bug.