Hi, if I run this program from command line in Linux, I allways get the same result, "/tmp/TMP00000.tmp". Shouldn't it return a different file name each time it's executed?.

How can I get different file names?

program tempfilename;
uses
  sysutils;
begin
  writeln(GetTempFileName);
end.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Did you delete the file after the run of your program? GetTempFileName always starts from 0 and checks whether that file already exists. If not, it returns that name else it continues increasing the index.

Regards,
Sven

Leonardo M. Ramé wrote

Hi, if I run this program from command line in Linux, I allways get the same result, "/tmp/TMP00000.tmp". Shouldn't it return a different file name each time it's executed?. How can I get different file names?

By actually creating the file. GetTempFileName does not create a file, but does check whether the filename exists.

Michael.

What is the use of that? Between the check and creating the file, some other process may already have created it.

Jonas

That's a security risk, because it is very easy to know what will be the file name. It should return random name that does not exists on a random length (that the developer chooses).

Symlink attack:
http://www.infosecwriters.com/texts.php?op=display&id=159for better understanding.

Ido

Well, I need to create BMP files with unique name, to be sent to lpr, then printed.  Instead of using GetTempFileName, I'll use a GUID, with CreateGUID, and GUIDToString.

Leonardo M. Ramé

http://leonardorame.blogspot.com

--- On Tue, 10/5/10, ik wrote:

That might be the reason why Windows is creating the file for you if you call GetTempFileName... so GetTempFileName in FPC does not expose the same behavior on non-Windows and Windows.

Regards,
Sven

Windows (or at least ReactOS) seems to use GetTickCount to generate a random filename:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/file/file.c?revision=48845&view=markup (look for GetTempFilenameW)

Regards,
Sven

This is always true on Unix, the only way to make sure is to have the kernel create the temporary name and file for you. Unix - to my knowledge - does not have a way to create and lock a file in one atomic operation; There are always 2 operations involved, and so anything can happen between the 2 calls.

That might be the reason why Windows is creating the file for you if you call GetTempFileName... so GetTempFileName in FPC does not expose the same behavior on non-Windows and Windows.

I'm open for some more sophisticated algorithm which does some more checking.

Michael.

You can at least open a file with O_CREAT|O_EXCL|O_NOFOLLOW to make sure that it does not yet exist at the point that you create it (and that it's not a symlink either).

Jonas

This is correct, but doesn't lock the file, and so it doesn't prevent someone from 'stealing' the file before the lock is applied. It's of course a remote possibility.

Personally, I have more problems with windows which actually creates the files and locks them. It sometimes requires a reboot to release the lock again in case something happens to the calling process.

That said, I repeat: no problem if someone implements a more secure algorithm.

Michael.

Locking is always advisory on Unix, so that doesn't matter anyway.

and so it doesn't prevent someone from 'stealing' the file before the lock is applied.

Nobody else can steal the file once you have created it, because they won't be the owner nor have the necessary permissions. That is the main security risk and it is solved by this approach. The fact that another process running under your login not using O_EXCL could overwrite it is not an extra security risk (if you have a rogue process running under your login, nothing that you do is safe because it can use ptrace to modify any process in any way it sees fit anyway).

Jonas

And that is why I think the whole point is hugely exaggerated :-)

But it doesn't mean we shouldn't do our best to make it minimally safe.

Michael.

It's not, because currently a process from *another* user can trivially intercept your temporary files. If you have a daemon running as root, that is a major security concern.

Jonas

Michael Van Canneyt ha scritto:

To avoid reinventing the wheel, POSIX provides:

int mkstemp(*char template)

( http://linux.die.net/man/3/mkstemp )

which does exactly what is required, i.e. it creates an unique name and opens the file for write with O_EXCL flag, and permissions 0600 (starting from glibc 2.0.7, before it was 0666), ensuring the uniqueness on success.

If libc dependency is not desirable, the same functionality can be reimplemented in fpc, using libc implementation as a guideline to maintain consistency in Unix environment.

Giuliano

I'm open for some more sophisticated algorithm which does some more checking. Michael.

Honour one of the temp directory environment variables, I know of TMPDIR, TEMP, TMP. I think it would be best to check them in order and then default to /tmp/. Create a folder in the temp directory naming it after the user name. E.g /tmp/myusername/ Ensure only the owner can read and write in the folder. Create a folder in "/tmp/myusername/" using your program name. Then create your temp file. so you have "/tmp/myusername/programname/tmp01"

You should only need to check for symlinks, hardlinks and read/write rights on the "/tmp/myusername" folder.

What is the cost?
Two more inodes
More cpu time
What do you get?
It hides the file's names
Good layout
Easier to use Tomoyo and Apparmour.

Windows (or at least ReactOS) seems to use GetTickCount to generate a random filename:

Do not you use random file names without a subdirectory because you can not use Tomoyo or Apparmour to lock the program down.

I use this trick with Firefox.
From my .bashrc file
mkdir /tmp/$USER >> /dev/null 2>&1
chmod u=rwx,g=rwx,o-rwx /tmp/$USER >> /dev/null 2>&1 export TMPDIR="/tmp/$USER" >> /dev/null 2>&1

#!/bin/sh
mkdir $TMPDIR/firefox/
env TMPDIR=$TMPDIR/firefox /usr/bin/firefox $@

From my Tomoyo profile:
allow_read/write /tmp/\*/firefox/\*
allow_rename /tmp/\*/firefox/\* /tmp/\*/firefox/\* allow_rename /tmp/\*/firefox/\*.part /home/\*/Downloads/\* allow_truncate /tmp/\*/firefox/\*
allow_unlink /tmp/\*/firefox/\*

Since there is no way to predict what the file name will be, permissions have to be done on a per folder basis, not per file.

I'm all for it, but I was kind of hoping for an implementation :-)

Michael.

Jonathan wrote

Create a folder in the temp directory naming it after the user name. E.g /tmp/myusername/ Ensure only the owner can read and write in the folder. Create a folder in "/tmp/myusername/" using your program name. Then create your temp file. so you have "/tmp/myusername/programname/tmp01"

The norm under my system, Ubuntu Linux 10.04 (and probably all other Linux systems too), is to use the format "<program>-<user>" as the temp directory. See the listing of my /tmp/ directory.

-------------------------------
srwxr-xr-x 1 graemeg graemeg 0 2010-10-06 14:47 gedit.graemeg.3293794453 drwx------ 2 graemeg graemeg 4096 2010-09-28 09:19 keyring-tTwy4j drwx------ 2 graemeg graemeg 4096 2010-10-06 16:29 mc-graemeg drwx------ 2 root root 4096 2010-10-01 09:27 mc-root drwx------ 2 gdm gdm 4096 2010-09-28 09:19 orbit-gdm drwx------ 2 graemeg graemeg 4096 2010-10-07 09:07 orbit-graemeg drwx------ 2 root root 4096 2010-10-01 09:27 orbit-root drwx------ 2 graemeg graemeg 4096 2010-09-28 09:19 pulse-6W7jC4ahCwwh drwx------ 2 gdm gdm 4096 2010-09-28 09:19 pulse-PKdhtXMmr18n drwx------ 2 graemeg graemeg 4096 2010-09-28 09:19 ssh-ksaXcs1548 drwxr-xr-x 2 graemeg graemeg 4096 2010-10-07 09:05 TempDUnitFiles -rw-r--r-- 1 graemeg graemeg 672364 2010-10-06 17:00 TMP00000.log drwx------ 2 graemeg graemeg 4096 2010-09-28 09:19 virtual-graemeg.pm1Pse -------------------------------

Aahhh.. Norms. Right. like all config files should go in ~/.config/, as proposed 5 years ago, because ~/.program/ is "not the norm" (dumping a successful 20-year old practise for no apparent good reason).

Meanwhile I'm still waiting for the first non-fpc app to write it's config files in that directory (using Kubuntu, BTW). All other apps I use still happily write in ~/.program/

Same on Microsoft: 'every program must be installed under C:\program files\'. Oh yes. Meanwhile more and more programs write NOT under C:\program files\ because it is more and more a pain in the *** with each new release of Windows.

So: Norms ? Thank you, but I'll pass on that and implement what I perceive as simple and correct :-)

Michael.

Michael Van Canneyt wrote

Meanwhile I'm still waiting for the first non-fpc app to write it's config files in that directory (using Kubuntu, BTW). All other apps I use still happily write in ~/.program/

Well, then here it is.... In my ~/.config/ I have the following non-FPC projects config files

* enchant
* f-spot
* google-chrome
* indicators
* helix
* gnome-disk-utility
* gnome-session
* gnome-mplayer
* gtk-2.0
* softwarecenter
* totem
* vlc
* ubuntuone
* WebIssues
* ...Qt too... there is a Trolltech.conf file, but not in a separate directory

All non-FPC apps Michael! So the word is spreading. ;-)

So: Norms ? Thank you, but I'll pass on that and implement what I perceive as simple and correct :-)

I don't perceive to know all the "unix/linux standards" or "unix norms"... I do know Midnight Commander (console file manager) is probably as old as Linux, and it too creates /tmp/mc-graemeg/ directory for any temp files it creates. That's a non-FPC app too. So I really don't understand your issue with what I said... maybe "norm" was not the correct word to use then?

PS:
I didn't get the /tmp/<program>-<user>/ information from freedesktops.org or any other website for that matter, I simply saw it created by a few linux applications I use, so thought I would mention it, as it is similar to what Jonathan suggested.

I'm just saying what Windows itself does and provides to its user per API.

Btw: What are Tomoyo and Apparmour (I can imagine what the second one is, but I don't know what functionality they provide)?

Regards,
Sven

I seem to have missed a few more...

* arora-browser.rog
* desktop-couch
* compiz
* DjVuLibre
* brasero
* beyondcompare (they use Kylix I think)

While debugging some config troubles in one of my FPC apps I've found some other config files in ".config" (I don't remember which ones and also I'm currently at the wrong computer, so I can't look it up). So there are non-FPC apps which write in there ^^

If the applications would keep their read only files in 'c:\program files' and write only into those directories that they should (e.g. user's appdata and global appdata (although this one should not be used for sharing writable files...)) we wouldn't have all these problems (virtual file store, UAC, etc.). And this "norm" should have been followed since NT 3.5 (in Win 9x there wasn't such a norm, because there was no real security ^^).
And when Microsoft merged the Win 9x and Win NT lines resulting in Windows XP they corrupted this norm to keep backwards compatibility with 9x applications. Oh how beautiful... -.-

Regards,
Sven

Some applications must write in the application directory.

Our apps do automatic updates at least once a month. The updates cannot be postponed. I don't see how this can be achieved without writing in the application directory.

Michael.

As "updating applications" is an administrative task it should only be done by those users that are allowed to do that. Normal users can't write to /usr/ on *nix either, so I don't know why all have trouble to accept that this is something a normal user should not do... (and no, I'm not taking "on 9x it was done that way" as an excuse :P )

Regards,
Sven

Yes, but if the administrator must update 20 PCs manually every 2 weeks, he quickly complains that he has better things to do, so it must be done when the 'ordinary' user uses the application.

I'm not making this up, it's just real life.

I am aware of the theory and the good practices, but in a commercial environment, different rules enter the game. I just haven't found a satisfying solution yet :-)

Michael.

But this is one of the tasks that a administrator should do. He should check that "his" computers are in good and up to date condition (that most admins think a bit different about this is another story...)

I'm not making this up, it's just real life.

That's the problem :(

I am aware of the theory and the good practices, but in a commercial environment, different rules enter the game. I just haven't found a satisfying solution yet :-)

Perhaps the correct solution would be to create a user group that's named e.g. "Michael's software users" and this group is granted write permission to your software's main directory. Now every user who uses your software is added to the group and voila! (that would even work on *nix systems)

I know that it isn't as easy as it sounds - we have similar problems with our customers - but this should be the best possible solution for this problem without "stressing" the admin to do to much work.

Regards,
Sven

Well, in schools the administrator is a teacher (usually maths or so) who gets the additional job of managing the schools' IT structure. And all our clients are schools.

Since that are usually all users of the PC, this amounts to giving all users write permission to the app directory, which is what the admins do now :-)

Anyway, just to say that 'norms' are nice, but practice is another story.

I'll see about a more 'safe' gettempfilename() which is what the discussion was all about in the first place.

Michael.

Michael Van Canneyt wrote

Well, in schools the administrator is a teacher (usually maths or so) who gets the additional job of managing the schools' IT structure. And all our clients are schools.

Schools are indeed a bit special... sometimes you have to be lucky if the teacher knows what an update is (even the "administrator" one)! (I know of such an example at one of my step mother's schools...)

Well... it's easier to kick someone out of the "Michael's software users" group than of the "Everyone" group :P (but at least the kids aren't admin users... that's something ^^)

We had a different topic?! I didn't notice that... *cough* (I'll be quiet now ^^)

Regards,
Sven

Btw: What are Tomoyo and Apparmour (I can imagine what the second one is, but I don't know what functionality they provide)?

http://tomoyo.sourceforge.jp/
https://wiki.ubuntu.com/AppArmor

Michael Van Canneyt wrote

Yes, but if the administrator must update 20 PCs manually every 2 weeks, he quickly complains that he has better things to do, so it must be done when the 'ordinary' user uses the application.

Aren't there automation systems for this? Just like debian's 'apt-get update && upgrade' with a custom repository with your software? But then for windows I presume?

Micha

I haven't seen any yet. The main problem is that the update isn't 'optional' or 'to be scheduled at X every night'.
It must be done when the server application says it is time to do so.

Michael.

Michael Van Canneyt wrote

I haven't seen any yet. The main problem is that the update isn't 'optional' or 'to be scheduled at X every night'. It must be done when the server application says it is time to do so.

apt-proxy ... push to the proxy when it's time to update stuff ;)

Micha

Sent from my iPhone

I've had to do this. It's extremely painful in Windows because there's no easy way to replace the executing application. Everything runs pretty smoothly till you need to update the section of the app that does the update! To assume that will never occur is to invite FAIL! it might be easier now that NT is the target, but 9x made it extremely hackish to get working.

Thanks.

So when changing/improving GetTempFileName we could also try to make it compatible to such applications by creating a directory in TEMP for the temporary file that contains the appname and the user. Windows isn't affected, because AppArmor and Tomoyo aren't usable there.

Regards,
Sven

The current implementation does just that. It uses GetTempDir which checks TEMP and TMP (in that order), and if neither is set, uses /tmp.

Note also that you can hook in the temporary filename mechanism by setting OnGetTempFile and doing it all yourself.

Michael.

I'm aware of that (btw: is this OnGetTempFile possible on Windows as well?). :)

But maybe we can use by default something like the following if HAS_GETTEMPFILENAME is not set (pseudo code):

if OnGetTempFilename  Nil then
   OnGetTempFilename(Prefix)
else begin
   dir := FindTempDir + PathDelim + GetAppName + '-' + GetUserName;
   CreateTempFileInDir(dir, Prefix);
end;

* FindTempDir searches for a suitable environment var (TEMP, TMP, /tmp)
* GetAppName uses the GetAppName that is used for GetConfigDir as well (might be named differently, I'm not looking at the source currently)
* GetUserName returns the name of the current logged on user (could be empty if the username can not be found)

Regards,
Sven

It should be ?

There is no user name info; at most the UID can be retrieved.

Secondly, the fallback should work on all platforms, so username etc. are not relevant.

We're discussing a unix solution, so this will be implemented for unix only.

Michael.

Seems that I'll need to check that.

Let me guess: UID->username is a libc function...

Secondly, the fallback should work on all platforms, so username etc. are not relevant.

Ok... what about providing an event for retrieving the temp directory? (or is there already?) Thus one can rely on the behavior that the file is created when you call GetTempFilename (which is a todo as we now know ^^) and one can also customize its location if one wants to support something like AppArmor, etc.

We're discussing a unix solution, so this will be implemented for unix only.

I'm aware of this.

Regards,
Sven

Sven Barth wrote

Let me guess: UID->username is a libc function...

It has to be implemented via a library, because the translation can be done in as many different ways as there are authentication systems (/ etc/passwd, NIS, kerberos, ActiveDirectory, ...).

Jonas

Sven Barth wrote

Let me guess: UID->username is a libc function...

Problem is you can't always map a UID to a username under Unix. The username is not always in the /etc/passwd file. You can have LDAP (I think that's what it's called), Kerberos etc... users. I noticed the same problem in fpGUI's file dialogs. So I wrapped that code in try..except calls. Try the local user (in /etc/passwd), if it fails to resolve, fall back to using the UID as is. On standard desktop linux this is 99% of the times ok, but in a large corporate environment things might be different.

Either way, using the UID should be fine too...or better that it currently is.

I haven't thought about "network users", so thank you Graeme and Jonas for the explanation.

Either way, using the UID should be fine too...or better that it currently is.

That's why I suggested at the end to provide a OnGetTempDir besides the OnGetTempFilename, so that only a part (e.g. tmp dir resolving) of GetTempFilename can be replaced.

Regards,
Sven

Well, I believe that the proper solution for this issue for Windows (fulfilling your needs) would be probably using a service running under an administrator account and installed together with the application. The service itself should be rather simple / generic in order not to have to update the service too. This service can check availability of a newer version periodically while the PC is running but the application is not (in order to avoid the user having to wait for the update on startup of the application) or do it on demand when triggered to do so by the application (using some sort of IPC).

Tomas

That was my idea as well.

Michael.