[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils
Subject:    Re: [coreutils] Is, 'df' when run as UID=0 NOT privileged ? Re, FAQ question 32 and tune2fs manpage
From:       Eric Blake <eblake () redhat ! com>
Date:       2010-11-12 15:07:25
Message-ID: 4CDD582D.40203 () redhat ! com
[Download RAW message or body]


On 11/12/2010 01:19 AM, Mike Hodson wrote:
> 'df' should report what said "privileged" user can write.
> 
> Why, if 'df' is run as UID=0, does it not report what UID=0 is able to consume?

Thanks for the report.  Remember, there's only one[*] syscall available
for querying the information: statfs().

[*] Technically, at the library level, there is both statfs() and
statvfs(); where the latter is the only variant standardized by POSIX.
But statvfs() doesn't expose as much information as statfs() on Linux,
and ultimately both glibc functions call into the same syscall.

> 
> I *expect* programs, run as the root user, to realize that things may
> be different than if run as a non-root user.
> 
> In pseudocode, this simple logic should work:
> 
> IF ((running_as_uid == superblock_privileged_uid) || (running_as_gid
> == superblock_privileged_gid))
>   {
>     get_fs_blocks_avail_for_privileged_user
>   }
> ELSE
>   {
>     get_fs_blocks_avail_for_normal_user
>   }
> ENDIF

For this to work in coreutils, it would require assistance from the
kernel, probably in the form of two syscalls.  That is, your pseudocode
would have to be folded into the kernel itself.

Therefore, if you REALLY think that you have a chance at convincing the
kernel guys to change the statvfs syscall to start reporting different
values based on euid==0, or to add a new syscall for just root to use,
then take it up with them.  But given the high cost of adding or
altering syscalls, I'm not holding my breath.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]