[clue-tech] Filesystem quotas circumvented

[Angelo Bertolli]

Keith Hellman wrote:

>On Tue, Jan 18, 2005 at 05:31:17PM -0500, Angelo Bertolli wrote:
>  
>
>>Apparently, it does have something to do with root
>>
>>[angelo at web1 angelo]$ yes > ~/tmp
>>ide0(3,2): warning, user block quota exceeded.
>>ide0(3,2): write failed, user block limit reached.
>>yes: standard output: Disk quota exceeded
>>
>>[angelo at web1 angelo]$ sudo yes > ~/tmp
>>[angelo at web1 angelo]$
>>[angelo at web1 angelo]$ quota
>>Disk quotas for user angelo (uid 635):
>>    Filesystem  blocks   quota   limit   grace   files   quota   
>>limit   grace
>>     /dev/hda2  161476* 100000  150000             353   10000   15000
>>
>>However, the file created is owned by angelo
>>
>>I thought sudo should only apply to the command in question, for example:
>>
>>[angelo at web1 angelo]$ yes > /root/tmp
>>bash: /root/tmp: Permission denied
>>[angelo at web1 angelo]$ sudo yes > /root/tmp
>>bash: /root/tmp: Permission denied
>>
>>Does anyone know the finer details on why this is the case?
>>
>>    
>>
>
>I believe the difference is that 
> $cd /
> $sudo ls -lhRt ~/lsr
>creates a file owned by angelo (indeed, it is created and connected to
>the child (about-to-exec-sudo) process while still having a uid of
>angelo.
>
>But, the process *writing* into ~/lsr has an effective user id of root
>(it is the sudo binary). My guess is that it is the process uid & gid
>that quota is considering, not the file owner's (angelo's) quota limits.
>
>I believe this explains most of the behaviour so far:
>- the initial query
>- why the $yes >~/tmp is quota impaired as expected (because the 'yes'
>  process is uid=angelo)
>- why the 
>   $yes >/root/tmp
>  and the
>   $sudo yes >/root/tmp
>  had permission denied (it is still angelo's shell trying to open up 
>  /root/tmp in both invokations, and presumably angelo doesn't have
>  permission to create /root/tmp).  In the latter case I suspect 'sudo'
>  was never even execd.
>
>What I don't quite understand is why the 
>  $sudo yes > ~/tmp
>(immediately following the $yes > ~/tmp ) didn't show a disk full error.
>Was some output omitted?  Was the process CTRL-C terminated?  Certainly
>the 'sudo yes' wrote something to the file because the shell would have
>recreated and thereby truncated (the too big) ~/tmp because the
>invokation is 'sudo yes > ~/tmp' not 'sudo yes >> ~/tmp'. I'm confused
>why this particular invokation a) apparently respected angelo's quota
>limitations whereas the original invokation did not, and b) doesn't display
>sometype of terminal message (disk full or CTRL-C).
>
>My 2c
>  
>
>
Thanks.

Yes,  `sudo yes > ~/tmp` was terminated with ctrl-c.  I also did try 
`sudo yes >> ~/tmp` and was not restricted at all:  it started appending 
to the file normally.

I'm still not sure why the `sudo yes > /root/tmp` doesn't work, given 
that the process created should have root permissions.  It seems to me 
like both should follow the same rule.

Angelo