The /tmp directory on any Linux/Unix system must be world writable. If it's not world writeable lots of things will break that write temporay files there. As long as it isn't exported and is only accessible from the local machine it doesn't constitute a security risk. That, of course, assumes that applications that use /tmp don't ever put sensitive data (user passwords, etc) in their temp files. The standard Linux tools and applications that use /tmp don't, but a user written application or a poorly coded web application might.

does not seem to addresst he issue.

What is broken by /tmp access descriptor set to 755 is
xfs -droppriv

this appear to work

chmod 777 /tmp
xfs -droppriv -daemon
chmod 755 /tmp

Anyone tested this approach or have a different solution. jlevie, could you be more specific and point to the list of applications that will fail if /tmp access mode is set to  755.

Cheers

Well, obviously xfs is one of the applications that breaks if /tmp isn't world writeable. Others that come readily to mind include some parts of Gnome, bcc, ed, ethereal, g++, gcc, g77, gimp, lpr (with certain options), mail, Mail, metamail, mhmail, mktemp, mutt, patch, several perl utils, pine, sane, scanimage, screen, tex, virtex, xdelta, yacc, zip, cvsbug, pam_krb5, restore just to name a few. /tmp is commonly used by shell scripts that invoke mktemp and applications like web servers that need a place where no special privs are required to write files. Checking the man pages for things that advertise the fact that they use /tmp will reveal quite a number of things, but not all. For example, xfs obviously uses it but the man page doesn't say so.

The standard behaviour on Linux & Unix systems is that /tmp will be world writable and programmers depend on that when writing applications and scripts. You could certainly work around the xfs problem by what you show above, but I'm sure that you are going to find lots of other things that will fail or require special treatment if /tmp isn't world writable.

Folks, anyone?

-- does xfs really need to write into /tmp after the daemon is initialized.

what applications broked by /tmp world readable ( non - writable )

Cheers

Yes, xfs will break if /tmp isn't world writable. It has to have someplace to create it's Unix socket for other applications to read font data from. And when --droppriv is used for security reasons xfs no longer runs as root, thus it can't create the socket in /tmp if it isn't world writable.

Any of the applications that I mentioned above may break if run by a non-root account if /tmp isn't world writable. And as I pointed my list is only a partial list. But it should be enough to illustrate the fact that you don't want to change the permissions on /tmp.

BTW: The correct permissions for /tmp are 1777, not 777.

"...
has to have someplace to create it's Unix socket for other applications to read font data from. And when --droppriv is used for security reasons xfs no longer runs as root, thus it can't create the socket in /tmp if it isn't world writable.
..."

sounds like you are catching up. With the fix I created xfs can, and already is continuing to run as user xfs and keep /tmp directory free from excessive privileges granted to the user everybody.

Is there a case when this fix caused xfs to break after a day / week / month. Developer is working or worked on it out there, and knows exactly what xfs writes into /tmp directory and when ( after daemon process has being initialized ) may be he or she will share his or her knowledge, so I hope and appreciate your help beforehand and will  grant my points.

Cheers

Keep in mind that /tmp is done for temporary things. Jlevie didn't tell it directly, but the idea is that /tmp MUST be world writable for normal system operation.

And yes, you can have very secure machines with /tmp world writable. Security is not denial of service.

--
Radu-Adrian Feurdean
Brainbench Linux MVP

Just to add a point, most applications also recognise a shell variable $TMPDIR or $TMP which need not point to /tmp.

I don't think I'd go so far as to say that most applications allow for env vars defining the temp directory, but a lot do. To me the whole idea of restricting access to /tmp for security reasons is sort of "much ado about nothing". A world writable /tmp doesn't constitute a security risk and changing what everybody believes should be the default behaviour will lead to failures of other things.

The security risk is not created by having /tmp world-writable...  if a security risk is present, it is created by individual applications that create their temporary files as world-writable (or even world-readable, if sensitive information is written).  

The solution here is simply not to use poorly written applications.  

Having a directory that anyone can write to is not a risk.  Having temp files that anyone can *overwrite* would be a different story, as it would create an easy hijack situation.  

FYI, the standard permissions for /tmp should be
chmod 1777 /tmp

The extra '1' sets the sticky bit, which keeps people from deleting each other's files.

Meanwhile, the big trouble with /tmp, aluded to by Techno_Mage pointed out, is that programs assume they are the _only_ programs that can write in /tmp. Particular issues are:

o Program writes to files in /tmp with well-known/guessable names without (atomically) checking that file is not a symbolic link. Allows attacker to pre-insert links to system files (such as /etc/passwd) causing the system files to get clobbered.

o Program writes to files in /tmp of user's choosing with elevated priveleges (similar to above).

miron - two possiblities here - take Jim's advice, or stop running unix - There are plenty of other things on the system that will freak you out if you can't handle the idea of a directory that has 1777 permissions...

Just my $.02
-Jon

Please reject Quirkyquirky's answer.  He has posted like this locking up questions in almost every category using 3 different names: EliteKiller, LiloXwin and  Quirkyquirky

run xfs in a chroot jail?
that way the /tmp it uses doesn't have to the THE /tmp.
/. just had an article on chroot, worth a quick look.

ok,

the trouble seems to go away, I still though a bit confused and the confusion comes from details. As much as digging into this heap of privilege manipulation seems counterproductive, I am truly eager to learn how exactly failure of xfs occur when privilege on /tmp is restricted to read execute only to non - privileged users. In this case I really need to delve into the workings, without having to learn source myself. So, my point is I am still looking to find help and I would appreciate if anyone knows xfs explain what is going on.

Thanks

The reason that xfs fails when /tmp is not writable by other than root is that xfs must create a directory (.font-unix) and a socket in /tmp. For security reasons xfs runs as user xfs, group xfs. So if /tmp is restricted to read, execute by other than root xfs will fail.

And has been mentioned numerous times in this thread there are other things that will break if /tmp isn't world writable.

well, I will let you know when we can close this article. The fact that xfs creates socket was definitely a detail, but not good enough to learn what it is doing so that it needs to be able to write to /tmp for as long as the machine is up and running.

-- cheers

The whole purpose of creating a named socket is to be able to read/write via that socket. If for no other reason that requires /tmp to world readable/writable. Keep in mind that xfs won't be running as the user that "owns" the X applications/display, but X will need to be able to communicate with xfs for font data. That means that at least two different users need read/write access to the socket.

please, disregard the latest comment in this question.

this question is still unsolved and need to be continued.

-- cheers

BTW, Venabili, thanks for volunteering in the linux dome, as I red your profile, Linux is not your area. Please, update your profile accordingly, here is the quote:


Page Editor at Experts Exchange in the following areas:

Programming Languages
Java
Game Programming (or Game Development) depending where you check the name :)
Game UI
3D Programming
AI &Physics
Consoles
Game Graphics
DirectX
OpenGL

Mail : venabili AT experts-exchange DOT com

My comment of 6/26 details one reason why /tmp needs to be world writeable. What part of that is unclear?

your input is much appreciated, however, I have the same feeling as you are, and would like to get a bit more information.

-- cheers

What more information do you need?

miron ,

There is a difference in Page editor and Cleanup Volunteer:)
I am not the PE here.. I am just helping to have the old quetsions closed - see the help page for more details on the process.:) I may add a list of all tyhe areas I clean in but.... it will be quite long I'm afraid

So what more information you need? (as jlevie  asked)

Venabili

And something more - 21 days after the last comment, the quetsion is abandoned and should be closed. So if you want it open, answer to the experts and keep it active. Otherwise - it will be closed.

Venabili

Well, here is the question when I started it, let me quote:
"
xfs needs write permissions into /tmp directory.
Such a "workaround" appears to me as a world writable share.
Is there bit more security consious solution.
"
then an additional clarification was added for clarification:
"
what is xfs and how it is doing what it needs so that it needs such a privilege
"

There is a number of reasons I asked this question. If you have input into the question, greatly appreciate it.

Regards,
Miron.

This has really been answered by the previous comments, but...

For security reasons xfs must not be run with root privs, but it does need write access to a temp area that is readable by everone. /tmp on a Unix or Linux system is made world writable (with the sticky bit set) to provide a place for any application running as any user to be able to create temp files that won't hold "sensitive data". So, following long standing convention the writers of xfs chose /tmp as the place to hold the temp files needs for the operation of xfs.

As pointed out, a lot of other things presume that /tmp will be world writable and will break if that's not the case. You could not install X, and thus not need to run xfs, but even so you'll find other applications will fail is /tmp isn't work writable.

This has really been answered by the previous comments, but...
-- first moot point

For security reasons xfs must not be run with root privs, but it does need write access to a temp area that is readable by everyone.
-- another moot point

/tmp on a Unix or Linux system is made world writable (with the sticky bit set) to provide a place for any application running as any user to be able to create temp files that won't hold "sensitive data"
-- another comment that is partially accurate and superfluous to the matter discussed.

Admin, please remove all comments from jlevie and venabily as immaterial.
If someone knows workings of xfs and would like to provide a good answer, I would like this person to see an accurate question so that a meaningful comment could be accepted as a good answer.

-- cheers

well,

1777 permissions on /tmp is not a "workaround" - they are the correct permissions for a unix system.

is a very interesting issue that deserves its separate overview. But the question is not about this issue.

I think we need to better cooperate here... and sart discussing xfs workings

-- cheers

I don't think my question changed, it is the bloat of answers of sorts that we are stack with now.

as far as making aducated guess at how to make xfs workings I submit to you that we should wait until an expert with expertise in the subject comes to the forum and looks up the question. Look with your own eyes, I stand free of correction here and the question does need to be addressed.

-- cheers