The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /tmp usage and security

bruce@pixar.com (Bruce Perens) writes:

> From: Kevin Dalley <kevin@aimnet.com>
> > The man page and info page for tmpfile do not mention that the file is 
> > deleted immediately, merely that it is deleted when closed or when the 
> > program is terminated. It would be nice to have a more explicit
> > explanation.
> 
> Yes. I happened to know how delete-on-terminate is implemented, but not
> everyone would.
> 
> > Of course, the creation/deletion is not an atomic operation.
> 
> Actually, create is atomic when you use (O_CREAT|O_EXCL) in the flags to
> open().


> > If there is a risk without tmpfile, then the risk remains with tmpfile,
> > though the risk is reduced because of the smaller window.
> 

> No window for open because of the flags, no window for rename because the
> directory has the sticky-bit set. It looks pretty safe.

Yes, the create is atomic, and the sticky-bit directory should make it
safe.  The creation and deletion combination is not atomic, but the
delete on terminate is irrelevant to security, though it reduces the
chances of garbage being left behind.

Your conclusion about the safety is the conclusion I had reached.
Assuming that sort opens its temporary files with the above mentioned
flags to open, sort (and updatedb) should be safe as it stands, though 
file names are visible to others in the /tmp directory.

If someone disagrees with my analysis, please describe how updatedb,
as run by cron, is insecure.  As findutils maintainer, I want some
confidence before I decide to ignore this report of a security
problem.  If there is a problem, then the problem lies with sort and
not with updatedb.

-- 
Kevin Dalley
kevin@aimnet.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .