LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 02-26-2015, 09:12 PM   #1
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Rep: Reputation: Disabled
Folder not readable or writable by any other system users


Hi all. I am tweaking my php.ini file and I do not understand the bolded text below...

http://phpsec.org/projects/phpsecinf...d_tmp_dir.html
Quote:
upload_tmp_dir

Test Description
Checks if the current upload_tmp_dir is a world readable or writable folder, and if it matches the common UNIX system temp directory.

Security Implications
upload_tmp_dir allows you to specify where uploaded files should be saved until the handling script moves them to a more permanent location. If this file is within the document root of the web site and/or accessible to system users other than PHP's user, it could be modified or overwritten while PHP is processing it. By default upload_tmp_dir is set to the system's standard temporary directory, which can typically be accessed by all system users.

Recommendations
Set upload_tmp_dir to a folder that is:
- outside the document root of your web site
- not readable or writable by any other system users

You can set upload_tmp_dir in the php.ini file:

; Set upload_tmp_dir to a safe location
upload_tmp_dir = /var/www/foo.bar/sessions

The setting can also be applied in apache's httpd.conf file, or an .htaccess file:

# Set upload_tmp_dir to a safe location
php_value upload_tmp_dir /var/www/foo.bar/sessions

Questions:
1.) What does the bolded text mean, and how do I do that?

**NOTE: I don't have VPS Root access, and am hoping this can be done using my regular account via SSH.

2.) Where would be a safe place to put these temporary files?

Sincerely,


Rob
 
Old 02-27-2015, 08:21 AM   #2
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,604

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
It pretty much means what it says.

The upload_tmp_dir is something you don't want users accesses outside the PHP control due to possible corruption (the referenced race condition).

You don't want it accessible by general users thus it should not be /tmp (which does happen to be the default) as it could be a problem with file naming conflicts (which could cause corruption).

Putting it outside the document root prevents other accesses to the web server from gaining access to the files - which can also cause the corruption.

Now, if you don't have general users (other than say yourself), then using /tmp shouldn't be a problem (though you might have to check SELinux security controls on RH systems for httpd to have /tmp access, usually it is disabled).

Their suggestion of using "/var/www/foo.bar/sessions" would be outside the document root(normaly "html"), isn't /tmp, and normally inaccessible by users (usually blocked at /var/www to read only access). It does have to have proper ownership (it will be used by the web server for read/write operations). If you are on a RH system, it must also have the proper security label (the type must allow writing, I think it would "unconfined_ubject_r:httpd_sys_rw_content_t:s0", where the type is "httpd_sys_rw_content_t")

Normally, the httpd configuration would be set by the system administrator. If you can set that, then you should be able to set the rest. I am assuming you are running under a VM, and have root access to the VM, but not the host of the VM.

Last edited by jpollard; 02-27-2015 at 08:23 AM.
 
1 members found this post helpful.
Old 02-27-2015, 10:46 AM   #3
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by jpollard View Post
It pretty much means what it says.

The upload_tmp_dir is something you don't want users accesses outside the PHP control due to possible corruption (the referenced race condition).
But does that mean it has to be in a location that I can't create or access since I don't have Root access on my VPS?


Quote:
Originally Posted by jpollard View Post
You don't want it accessible by general users thus it should not be /tmp (which does happen to be the default) as it could be a problem with file naming conflicts (which could cause corruption).
Is there anything that is safe to place in "/tmp" ??


Quote:
Originally Posted by jpollard View Post
Putting it outside the document root prevents other accesses to the web server from gaining access to the files - which can also cause the corruption.
I'm not following you on this one - I think some words got mangled!

Also, what is "document root"? Is that what I call "Web Root" (i.e. "/public_html")?


Quote:
Originally Posted by jpollard View Post
Now, if you don't have general users (other than say yourself), then using /tmp shouldn't be a problem (though you might have to check SELinux security controls on RH systems for httpd to have /tmp access, usually it is disabled).
My VPS runs CentOS 6. I don't have Root access. There is one VPS account called "rob123". (Of course my web host has "root" access to my VPS.)



Quote:
Originally Posted by jpollard View Post
Their suggestion of using "/var/www/foo.bar/sessions" would be outside the document root(normaly "html"), isn't /tmp, and normally inaccessible by users (usually blocked at /var/www to read only access). It does have to have proper ownership (it will be used by the web server for read/write operations). If you are on a RH system, it must also have the proper security label (the type must allow writing, I think it would "unconfined_ubject_r:httpd_sys_rw_content_t:s0", where the type is "httpd_sys_rw_content_t")
That went over my head!


Quote:
Originally Posted by jpollard View Post
Normally, the httpd configuration would be set by the system administrator. If you can set that, then you should be able to set the rest. I am assuming you are running under a VM, and have root access to the VM, but not the host of the VM.
See above.


What I ended up doing was to create this new directory...
Code:
upload_tmp_dir = /home/rob123/tmp_upload/
And I gave it 700 permission.

Is that okay?


Rob
 
Old 02-27-2015, 04:57 PM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,604

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
Quote:
Originally Posted by RobInRockCity View Post
But does that mean it has to be in a location that I can't create or access since I don't have Root access on my VPS?
Not having root on the machine means that you cannot configure the web server. And that makes it rather difficult, if not impossible, to meet the security requirements of the web server.
Quote:

Is there anything that is safe to place in "/tmp" ??
A directory. The problem is how the web server is configured. Normally it runs as an independent user to isolate it from other users. For you, not being root, means that you cannot create any directory that the web server can access that other users cannot also access.
Quote:
I'm not following you on this one - I think some words got mangled!
It depends on the system the web server is running on. If it is RH based, then the web server is also running in a security compartment that prevents it from accessing anything that is not explicitly labelled for the web server to be accessed - even if that data is owned by the account the server is running under.
Quote:
Also, what is "document root"? Is that what I call "Web Root" (i.e. "/public_html")?
If you look at the configuration file for apache, there is a directive "RocumentRoot" that identifies what the web server uses as the base for URL interpretation. All URLs are interpreted to be within that directory tree, with the assumption that this is the only data the web server will provide.

There are additional directives such as UserDir that define access to other directories (specified by the path given) that allow the web server to access them - usually as "http://hostname/~user/...." but access to a directory owned by the user, MUST grant either world access or the user has to be in the same group the web server runs under and grants group access.

Neither of these allow (by default) the web server to actually WRITE data (security hazard). In RH systems, even if the web server has read/write, it cannot do either unless the security label grants permission.

And if there are multiple users on the system, then these OTHER users may also access these files.
Quote:


My VPS runs CentOS 6. I don't have Root access. There is one VPS account called "rob123". (Of course my web host has "root" access to my VPS.)
This will be a problem meeting the requirements. CentOS IS a RH based system, and thus uses security labels unless it has been disabled.

Quote:
That went over my head!
You need to find out exactly what you are allowed to do - and none of it will encompass the security specifications of the package listed.

It assumes you are the system administrator trying to set up a secured web server.

Quote:
What I ended up doing was to create this new directory...
Code:
upload_tmp_dir = /home/rob123/tmp_upload/
And I gave it 700 permission.

Is that okay?
I don't think it will help - no one but you will be able to access that directory, including the web server.
Quote:

Rob
 
1 members found this post helpful.
Old 02-27-2015, 05:42 PM   #5
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by jpollard View Post
Not having root on the machine means that you cannot configure the web server. And that makes it rather difficult, if not impossible, to meet the security requirements of the web server.
That's a bummer. (I thought I was doing pretty well until now.)


Quote:
Originally Posted by jpollard View Post
A directory. The problem is how the web server is configured. Normally it runs as an independent user to isolate it from other users. For you, not being root, means that you cannot create any directory that the web server can access that other users cannot also access.
You keep saying "other users". Who ae they?

The only person on my VPS is me (i.e. "/home/rob123/")


Quote:
Originally Posted by jpollard View Post
It depends on the system the web server is running on. If it is RH based, then the web server is also running in a security compartment that prevents it from accessing anything that is not explicitly labelled for the web server to be accessed - even if that data is owned by the account the server is running under.

If you look at the configuration file for apache, there is a directive "DocumentRoot" that identifies what the web server uses as the base for URL interpretation. All URLs are interpreted to be within that directory tree, with the assumption that this is the only data the web server will provide.

There are additional directives such as UserDir that define access to other directories (specified by the path given) that allow the web server to access them - usually as "http://hostname/~user/...." but access to a directory owned by the user, MUST grant either world access or the user has to be in the same group the web server runs under and grants group access.

Neither of these allow (by default) the web server to actually WRITE data (security hazard). In RH systems, even if the web server has read/write, it cannot do either unless the security label grants permission.

And if there are multiple users on the system, then these OTHER users may also access these files.

This will be a problem meeting the requirements. CentOS IS a RH based system, and thus uses security labels unless it has been disabled.

You need to find out exactly what you are allowed to do - and none of it will encompass the security specifications of the package listed.

It assumes you are the system administrator trying to set up a secured web server.
Guess that means I have to spend more money that I don't have to pay advanced support to do this for me...


Quote:
Originally Posted by jpollard View Post
I don't think it will help - no one but you will be able to access that directory, including the web server.
Lovely.


Rob
 
Old 02-27-2015, 05:57 PM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,604

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
Quote:
Originally Posted by RobInRockCity View Post
That's a bummer. (I thought I was doing pretty well until now.)




You keep saying "other users". Who ae they?
Have no idea - at a minimum though, is root.
Quote:
The only person on my VPS is me (i.e. "/home/rob123/")
And whoever configures the web server, and maintains the security of the system.
Quote:

Guess that means I have to spend more money that I don't have to pay advanced support to do this for me...

Lovely.


Rob
Usually, it means you use the system as THEY defined your support to be. And that appears to exclude control over the web server.
 
Old 02-27-2015, 10:32 PM   #7
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by jpollard View Post
Usually, it means you use the system as THEY defined your support to be. And that appears to exclude control over the web server.
So here is the link from my OP...

http://phpsec.org/projects/phpsecinf...d_tmp_dir.html

Your comment above implies I should follow how my web host set things up versus how PHPSec is recommending that I harden my php.ini file.

Is that correct?


Rob
 
Old 02-27-2015, 11:26 PM   #8
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,604

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
You don't have any choice.
 
Old 02-28-2015, 12:12 AM   #9
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by jpollard View Post
You don't have any choice.
I do have a few choices.

1.) I could pay advanced support to do all the fancy stuff you mentioned above, and make it so Apache recorgnizes my folder called "tmp_uploads". (And I could start fasting to pay for it.)

2.) I could request Root, and dare to trigger the Apocalypse!

3.) I could hope that whatever IMH chose as defaults will work for my upload script. (Not a good idea if you ask me!)


Another challenge to tackle...

Gee, all of this web-hosting stuff is really dragging down the fun of finally getting ready to "go live"! *sigh*


Rob

Last edited by RobInRockCity; 02-28-2015 at 12:14 AM.
 
Old 02-28-2015, 12:23 AM   #10
Miati
Member
 
Registered: Dec 2014
Distribution: Linux Mint 17.*
Posts: 326

Rep: Reputation: 106Reputation: 106
Why not define it to a plae you do control? Like your home directory?
Quote:
outside the document root of your web site
- not readable or writable by any other system users
So if your web server is going to be located at ~/webserver/root_of_dir/ place it in ~/webserver/upload_tmp/

As for the second, limit the directory permissions to be 700. This means only you (the owner) can access the directory.
Obviously, root can access any directory whenever though.

Even a single user computer has many users. For example, the apache webserver runs as www-data (or nobody maybe) with very limited permissions to limit potentially damage if apache is hacked. It's a method of damage control.

If the place to serve web pages is indeed on /var/www and you don't have access.. well you're pretty much screwed. That's something to talk to your VPS about.

Quote:
I do have a few choices.
Could always go with a new server for web hosting that's more friendly.
I like nearlyfreespeech - but it's not designed to be friendly.
There's also many others that make it very easy (albeit more expensive)

Just something to consider before spending more money.

Last edited by Miati; 02-28-2015 at 12:29 AM.
 
Old 02-28-2015, 12:41 AM   #11
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 3,889
Blog Entries: 1

Rep: Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007
Quote:
Originally Posted by RobInRockCity View Post
I do have a few choices.

1.) I could pay advanced support to do all the fancy stuff you mentioned above, and make it so Apache recorgnizes my folder called "tmp_uploads". (And I could start fasting to pay for it.)

2.) I could request Root, and dare to trigger the Apocalypse!

3.) I could hope that whatever IMH chose as defaults will work for my upload script. (Not a good idea if you ask me!)


Another challenge to tackle...

Gee, all of this web-hosting stuff is really dragging down the fun of finally getting ready to "go live"! *sigh*


Rob
Yea, there are a lot of things that must be considered beyond the HTML when deploying a web site. It is only not fun if you don't understand much of the why and how. But you are learning, even if it is the hard way!

As to the php temporary file location - that is mostly important if you are on a shared hosting platform where there are other users not known to you. Uploaded files that spend time in the system /tmp directory may be accessible to them.

It is probably less important on a VPS where you are the only user - there should be no one else there to see them, and if there is someone else there, temporary file location is the least of your problems!

But still (excluding RedHat-isms mentioned by jpollard), /home/rob123/temporary_uploads should be a safe enough location with proper permissions. Assuming that your web server runs as the apache user and group, this should work:

Code:
mkdir /home/rob123/temporary_uploads
chgrp apache /home/rob123/temporary_uploads
chmod 770 /home/rob123/temporary_uploads
If your webserver does not run as apache, set the group to the same group as files in your website tree.

"Outside your document root" basically means a location that cannot be hit by a browser. Assuming your document root to be /home/rob123/www or something like that, anything NOT under the .../www/ directory will do. The reason is that a common attack vector is for a badguy to upload a malicious php script and hit the upload location with their browser to gain access to your site. By putting the temporary location outside the document root - they can't hit it. This ALSO presumes that you check it before moving it to a permanent location too... more to do!

"Not readable or writeable by any other system users"... well, if you are the only system user on your VPS that base is adequately covered by /tmp. If you are on a shared host it is not.

Just curious, who is your VPS provider and what does their plan provide if root access is extra cost? To my own mind, VPS implies root access.

And root access is not apocalyptic - just requires knowledge and care - not a place to just try things!

Last edited by astrogeek; 02-28-2015 at 12:45 AM. Reason: typs, tpos, typos...
 
1 members found this post helpful.
Old 02-28-2015, 07:09 AM   #12
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,604

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
Quote:
Originally Posted by Miati View Post
Why not define it to a plae you do control? Like your home directory?


So if your web server is going to be located at ~/webserver/root_of_dir/ place it in ~/webserver/upload_tmp/
Because that violates the desired security recommended by the package.
Quote:

As for the second, limit the directory permissions to be 700. This means only you (the owner) can access the directory.
Obviously, root can access any directory whenever though.
In which case, the web server also cannot access the directory.
Quote:

Even a single user computer has many users. For example, the apache webserver runs as www-data (or nobody maybe) with very limited permissions to limit potentially damage if apache is hacked. It's a method of damage control.

If the place to serve web pages is indeed on /var/www and you don't have access.. well you're pretty much screwed. That's something to talk to your VPS about.


Could always go with a new server for web hosting that's more friendly.
I like nearlyfreespeech - but it's not designed to be friendly.
There's also many others that make it very easy (albeit more expensive)

Just something to consider before spending more money.
 
Old 02-28-2015, 01:47 PM   #13
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by astrogeek View Post
Yea, there are a lot of things that must be considered beyond the HTML when deploying a web site. It is only not fun if you don't understand much of the why and how. But you are learning, even if it is the hard way!
Well, first of all, my website is more than "HTML" - trying over 50,000 lines of hand-written code...

But, yes, I underestimated how much there is to web hosting and systems administration! (Nonetheless, I genuinely eager to learn as much as possible and someday become gurus like you guys!)


Quote:
Originally Posted by astrogeek View Post
As to the php temporary file location - that is mostly important if you are on a shared hosting platform where there are other users not known to you. Uploaded files that spend time in the system /tmp directory may be accessible to them.

It is probably less important on a VPS where you are the only user - there should be no one else there to see them, and if there is someone else there, temporary file location is the least of your problems!
Okay, that is a good point. (I'm just trying to follow php.ini hardening advice I have found online to be doubly secure.)


Quote:
Originally Posted by astrogeek View Post
But still (excluding RedHat-isms mentioned by jpollard), /home/rob123/temporary_uploads should be a safe enough location with proper permissions. Assuming that your web server runs as the apache user and group, this should work:

Code:
mkdir /home/rob123/temporary_uploads
chgrp apache /home/rob123/temporary_uploads
chmod 770 /home/rob123/temporary_uploads
If your webserver does not run as apache, set the group to the same group as files in your website tree.
Okay.


Here is what my php.ini files says...
Code:
;;;;;;;;;;;;;;;;
; File Uploads ;
;;;;;;;;;;;;;;;;

; Whether to allow HTTP file uploads.
file_uploads = On

; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
;
;upload_tmp_dir =
upload_tmp_dir = /home/rob123/tmp_upload/
I guess I need to find out what the default location is.

As long as it is outside of the Web Root, it sounds like wherever it is will be okay in my situation.

Then again, I would hope that it doesn't take much to include the new directory above in CentOS 6's "security directives" or whatever they are called?!


Quote:
Originally Posted by astrogeek View Post
"Outside your document root" basically means a location that cannot be hit by a browser.
I think we are just using different terms for the same thing. I've always heard it called the "Web Root" - to emphasize things that can interact with the Internet.

Sounds like you guys use the term "Document Root".



Quote:
Originally Posted by astrogeek View Post
Assuming your document root to be /home/rob123/www or something like that, anything NOT under the .../www/ directory will do. The reason is that a common attack vector is for a badguy to upload a malicious php script and hit the upload location with their browser to gain access to your site. By putting the temporary location outside the document root - they can't hit it. This ALSO presumes that you check it before moving it to a permanent location too... more to do!
My upload script is about 1,500 lines of code and does over a dozen checks to make sure an uploaded picture is indeed a picture. Of course, placing it outside the Web Root only makes things even more secure.


Quote:
Originally Posted by astrogeek View Post
"Not readable or writeable by any other system users"... well, if you are the only system user on your VPS that base is adequately covered by /tmp. If you are on a shared host it is not.
Okay.


BTW, some people have mentioned that another reason to create a temporary folder is to avoid collisions. Do I need to be concerned about that?

I assume that PHP is smart enough to make sure that things like Sessions and Temporary Upload Files are unique.


Quote:
Originally Posted by astrogeek View Post
Just curious, who is your VPS provider
InMotion Hosting.


Quote:
Originally Posted by astrogeek View Post
and what does their plan provide if root access is extra cost? To my own mind, VPS implies root access.
On my VPS, root access is free, but not included out of the box.

Thusfar, I have chosen not to have them turn it on, because I don't feel competent enough.

At the same time, I am starting to see that there are lots of things I need to do - or at least research - that I cannot without VPS root access.

This weekend will be very telling for me...

I hope to upload all of my code to my VPS - database code was already installed last week.

If my website runs okay in UAT, then I will leave things as they are for the time being. (I think the only thing left that I need VPS root access for is this temp folder issue.)

Assuming my website works okay after "go live", then maybe a few months down the road I will come up with an attack plan, and request Root access. But for now, as long as my website runs - and is secure - it is not my priority to play all day with Linux. (Nothing personal.)

I have always been of the mindset that if you understand how things work, you can be a better owner and operator. So I am totally into learning all about Linux and web hosting and so on!!

At the same time, my #1 priority is having a website that makes $$$. And assuming I have reasonable server security, I think my time is best spent on how my website looks and feels and CONTENT!!

One thing I have noticed about IMH is they seem to really caution me on acquiring Root access, "because you might break something we can't fix!!"

I sort of wonder if that is in reality a little self-serving, and their larger goal is just to keep me dependent on paid advanced support.


Quote:
Originally Posted by astrogeek View Post
And root access is not apocalyptic - just requires knowledge and care - not a place to just try things!
This is what I am thinking...

Assuming my $$$ situation improves, in a few months I will get a second, identical VPS with this current web host. And on this second account, I will ask for VPS Root access up front - this will be my "test box".

That way I am learning on the same environment as my live VPS, and if I break anything, nothing lost.

I think an extra $40/month would be money well spent! And hopefully after playing around with things for a few months, I would be ready to implement any and all Root changes on my production VPS.

Time will tell...

Sincerely,


Rob

Last edited by RobInRockCity; 02-28-2015 at 01:53 PM.
 
Old 02-28-2015, 02:17 PM   #14
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,604

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
It is usually easier to setup a VM of your own and do the testing there.

Your only need then is to replicate the environment provided by InMotion Hosting.

The advantage of your own is that you don't have to depend on them if something you are testing goes south and kills the system.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Scripting, counting the number of readable, writable, and executable items Kratos22 Programming 9 11-29-2010 02:43 AM
cant mount readable writable = no boot? jerf Slackware 11 02-13-2009 08:57 PM
Making New Drive Readable and Writable on Windows XP and Linux tini1212 Linux - General 1 08-29-2004 07:06 PM
More than 32 GB hard disk, should be writable from Linux and readable from windows inditrozen Linux - Hardware 5 08-17-2004 04:42 AM


All times are GMT -5. The time now is 06:20 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration