Re: 10.4 and new File now longer works for uploading a file
Re: 10.4 and new File now longer works for uploading a file
- Subject: Re: 10.4 and new File now longer works for uploading a file
- From: Sacha Mallais <email@hidden>
- Date: Tue, 26 Jul 2005 17:35:53 -0700
On Jul 26, 2005, at 4:58 PM, Chuck Hill wrote:
On Jul 26, 2005, at 4:47 PM, Baiss Eric Magnusson wrote:
Yes the command
sudo -u appserver touch /Library/WebServer/Documents/nwsufis/
Flyers/Tarball.txt
fails with a permissions problem.
That is what I expected.
To create a file in a given dir, ONE (or more) the following needs to
be true in the immediate parent directory:
- the user writing the file owns the dir and the user has write
permissions
- the directory's group is one that the user belongs to and that
group has write permissions
- everyone has write permissions
Additionally, ALL parent directories must have ONE (or more) of the
following be true:
- be owned by the user writing the file and the user has execute
permissions
- the directory's group is one that the user belongs to and that
group has execute permissions
- everyone has execute permissions
To summarize: the user writing the file needs to have execute
permission on all directories leading up to where the file will be
written (which, in *nix-land, means "can open this dir and see what's
inside"), AND must also have write permissions on the directory that
the file is being written to.
The above command tests both conditions at once, so to determine if
this is a problem with not being able to execute a directory, do this:
sudo -u appserver cd /Library/WebServer/Documents/nwsufis/Flyers/
If that succeeds, then you know that the problem is that you cannot
write to that directory. If it fails, then somewhere along that path
is a directory that is not executable by the appserver user. Note
that these rules imply (correctly :-) that all directories in the
path save the last require execute permissions only.
ASIDE: There are ways to get around needing the execute permissions
of every dir in the path. Simply create a soft link to that
directory from somewhere that the user can write to. For example,
try this (replace <username> with your user name):
sudo -u appserver cd /Users/<username>/Documents/Public/Drop\ Box
It should fail with:
/usr/bin/cd: line 4: cd: /Users/sacha/Documents/Public/Drop Box: No
such file or directory
Why "No such file...", when it obviously exists? Because the
appserver user does not have execute permissions on Public, and
therefore cannot open Public up and see what's inside. Not the best
error message, perhaps, but that is the reason. If, on the other
hand, you create a soft link to that dir:
cd /tmp
ln -s /Users/sacha/Public/Drop\ Box/ test
Then try to write to the soft link "test":
sudo -u appserver touch /tmp/test/afile
That will work! Why? Because the directory that disallows access
(Public) is bypassed with the soft link. It is definitely not a good
idea to do this kind of thing, but it is important to be aware of in
a multi-user system and (hopefully) will give you more insight into
the wild and whacky world of *nix permissions!
HTH,
sacha
--
Sacha Michel Mallais
President / Developer Extraodinaire
Global Village Consulting Inc. http://www.global-village.net/
The bird of paradise alights only upon the hand that does not grasp.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden