[clue-tech] Filesystem quotas circumvented

[Keith Hellman]

On Tue, Jan 18, 2005 at 05:31:17PM -0500, Angelo Bertolli wrote:
> Greg Knaddison wrote:
> 
> >On Tue, 18 Jan 2005 15:16:03 -0500, Angelo Bertolli
> > 
> >
> >>So today I tried to do this (as user angelo):
> >>
> >>cd /
> >>sudo ls -lhRt > ~/lsr
> >>
> >>   
> >>
> >
> >What happens if you remove the sudo?
> >
> >Basically I think that the sudo is over-riding your quota (just a
> >guess).  If you are using sudo to get around permissions errors, why
> >not do something else that will produce great volumes, like
> >
> > 
> >
> 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

-- 
Keith Hellman                             #include <disclaimer.h>
khellman at mcprogramming.com                from disclaimer import standard
public key @ www.mcprogramming.com

"I like long walks, especially when they are taken by people who annoy
me."

-- Noel Coward
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://cluedenver.org/pipermail/clue-tech/attachments/20050119/7299471f/attachment.bin