gpg on open file

[Fabrice RAFART]

Hi,

Thank for you answer.

My problem is not to prevent a file from being modified during gpg work but
to prevent gpg to work on an open file.

I understand there is no feature in gpg for this.

So I do :

sudo fuser -v ${fic} || gpg ...

Ps : I find snapshhot and chattr good ideas in your case.

Regards,

Cordialement,
-- 
Fabrice Rafart
DSI - Responsable infrastructure et production.
Etablissement Français du Sang, Ile de France. 

> -----Message d'origine-----
> De : gnupg-users-bounces at gnupg.org 
> [mailto:gnupg-users-bounces at gnupg.org] De la part de Hauke Laging
> Envoyé : lundi 29 mars 2010 13:58
> À : gnupg-users at gnupg.org
> Objet : Re: gpg on open file
> 
> Am Montag 29 März 2010 10:04:13 schrieb Fabrice RAFART:
> 
> > Can I prevent gpg to encrypt open file ?
> > 
> > I explain my situation : I have file dropped to filesystem 
> by Windows
> > program with samba share. I take (with a script launch by 
> cron) the file
> >  and encrypt it. It may append that gpg take the file 
> during the Windows
> >  programm copy it.
> > 
> > For the now, I looking to use fuser to check this before 
> encrypt the file
> > but it may be a better way to prevent this.
> 
> I don't think that there is any solution within gpg, simply 
> because gpg cannot 
> (easily) prevent other processes from modifying the file 
> while it reads it.
> 
> I see two solutions, a usable one and the perfect one:
> 
> a) Use mandatory locks. That's what I wanted to suggest 
> first. But a short 
> look at the documentation make me think that this may easily 
> become terrible. 
> So better look at
> 
> b) Create a snapshot volume This requires the file's 
> filesystem to reside on a 
> block device that is handled by the device mapper. Locking a 
> whole volume in 
> order to emulate a reliable file lock looks a bit like 
> overkill but without 
> better solutions... This requires superuser privilege, of 
> course (in contrast 
> to (a)).
> 
> c) One more comes to my mind: Given that the file resides on 
> a suitables file 
> system (like ext{2,3,4} and probably more) you could make the 
> file immutable 
> (chattr), execute the next step and remove the i bit then. 
> Again: Superuser 
> only.
> 
> The snapshot's advantage is that is causes the shortest block 
> (if the file has 
> a relevant size) and that applications do not notice this 
> action. If an 
> application is not prepared for being denied access due to 
> mandatory locking 
> or the immutable bit, additional problems may arise.
> 
> 
> CU
> 
> Hauke
>