Re: imap4d LIST and DELETE

[Alain Magloire]

> 
> >     a00 LIST "" #comp.os.*
> > 
> > To have the entire comp.os hierarchy newsgroup.  Or the imapd server
> > could be on top of an SQL db, so:
> > 
> >     a00 LIST "/" *
> > 
> > may make sense.
> Sure, but for unix filesystem, I suppose, we would better be more
> cautious. Rfc states that:
> 
>       Server implementations are permitted to "hide" otherwise
>       accessible mailboxes from the wildcard characters, by preventing
>       certain characters or names from matching a wildcard in certain
>       situations.  For example, a UNIX-based server might restrict the
>       interpretation of "*" so that an initial "/" character does not
>       match.
> 
> Since imap4d/list.c is currently oriented only on filesystem-based
> mailboxes, we can make use of this statement and prevent user
> from seeing mailboxes whose full path does not end in or under
> his homedir. Or better yet, list_file() could check the ownership and
> list only files owned by the user. What do you think?
> 
> > We could restrict CREATE/DELETE/RENAME etc ... to /home/user/Mail/*
> > when accessing the filesystem?  But is that the right approach ?
> > is it not to restrictive?  Is there an actual benifice/advantage?
> Well, it sounds reasonable enough... The actual advantage is
> preventing the user from accidental (or even premeditated)
> destruction of other files. And we are still conforming to the rfc:
> it does not even define what the "mailbox" is, so it is completely
> implementation-dependent.
> 
> After all, these are the implementation details: I believe that
> for the end user it doesn't make much difference how exactly
> commands like, say
> 
>      a001 LIST "~/drafts" "*"
> 
> are mapped onto the server filesystem contents, what does matter for
> him is to get the proper functionality. From the other hand, the
> `/home/user/Mail' approach is much more safer...
> 

Ok, but it is a little tricky:

1- The implementation to "jail" file access to "/home/user/Mail"  for example:

  a001 LIST ""  ../../../../../../../../../../etc/passwd

  a002 LIST ""  ../../../../../../../../../../Mail/junk

  a003 DELETE //../../../../../../home/user/Mail/junk

  a004 LIST "" /home/user/Mail/junk

  a005 LIST "" /home/user/junk

  a006 LIST "" ~user/Mail/junk

  a007 LIST "" ~/Mail/junk

  a008 LIST "" ~/junk

if "/" maps to "/home/user"

should a001 succeed?
should a002 succeed?
should a003 succeed?
should a004 succeed?
should a005 succeed?
should a006 succeed?
should a007 succeed?

etc ..

2- Using chroot () is probably not a good idea, because INBOX
   still could map to /var/mail/user.

3- You may wish to provide shared mailboxes access, like
    ~bugzilla/Mail/PRs
   where users can access different PR's etc ...

4- point (3) does not go well with your idea of only listing
   the files own by user.   Imap servers are use
   a lot to provide multiple access safely to a single mailbox
   within an organisation, usually the bug database or the PR's etc ...
   (NOTE: there is a draft implementation to support this ing mailutils
   imap4d(see imap4d/sync.c) but I lack experience on this and I'm not
   sure on the right way of providing this, but that's another debate 8)

5- What about users with a second account:

    a00 SELECT ~mysecond_account/Mail/sent


--
au revoir, alain