Or, second best, is there a way to allow a user to only put files on your
box?
(Changing permissions on the given files to remove read access is not an
option.)
Thanks,
Fabio
I see nothing much for the stock ftpd, but if you install wu-ftpd, then
the ftpaccess man page offers:
data-limit [<raw>] <in|out|total> <count> [<class>]
Limit the number of data bytes a user in the given class may
transfer. The limit may be place on bytes in, out or total.
If no class is specified, the limit is the default for classes
which do not have a limit specified. The optional raw parameter
applies the limit to total traffic rather than just data files.
--
JP
I can't think of one.
| Or, second best, is there a way to allow a user to only put files on your
| box?
You might weave some spaghetti with "upload", permissions on incoming files,
etc.
How about installing ssh and let the users upload files with scp. That
keeps them from even seeing what is on the target box.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
Are you talking about anonymous ftp?
+(Changing permissions on the given files to remove read access is not an
+option.)
Why is that? The usual method (for anonymous ftp) is to use the 'upload'
keyword to set the permissions on uploaded files such that the user can't read
them back, e.g.:
upload /u/ftp /incoming yes ftp group 0044 nodirs
John
--
John DuBois jo...@sco.com KC6QKZ/AE
I wish to God these calculations had been executed by steam. - Charles Babbage
Thanks,
Fabio
| > +In SCO 5.0.x is there any way to allow a user to ftp into your box,
| > +and have all functionality EXCEPT retreiving files?
| >
| > Are you talking about anonymous ftp?
| >
| > +(Changing permissions on the given files to remove read access is
| > not an option.)
| >
| > Why is that? The usual method (for anonymous ftp) is to use the
| > 'upload' keyword to set the permissions on uploaded files such that
| > the user can't read them back, e.g.:
| >
| > upload /u/ftp /incoming yes ftp group 0044 nodirs
|
| No, I am not talking about anonymous FTP. We don't use anonymous
| FTP for a variety of reasons. I want a user who is a valid user on
| my system to be able to upload files to a specific directory, but
| not download anything already in that directory. I can not change
| permissions on the existing files because they need to have global
| read access for other reasons.
John already told you. You set that directory so that no one can read
it, anyone can upload to it, and every file uploaded immeidately gets
its permissions/ownership changed
--
JP
I'm sorry if I am not being clear. Changes file permissions on the
directory or the file IS NOT an option. I was wondering if there were any
way to disable the "get" feature in ftp, I guess not.
Fabio
Install wu-ftpd, and set up 'noretrieve' in the ftpaccess control file.
--
JP
He did say that everyone needs to have global read access in a
part of the message edited out. That sort of flies in the face of
having users who can upload but can't download because their normal
permission would apply, would they not? I'd think perhaps making a
special user for upload to that directory and make a special group
for that user and then set that users umask to 0040, not the 0044
above, and they would then create files not readable by the upload
group.
The 0044 from above would mean that only the owner of the file
could read it.
I'm not sure we know exactly what he's trying to accomplish.
--
Bill Vermillion - bv @ wjv . com
>Jean-Pierre Radley <j...@jpr.com> wrote in message
>news:2001020418...@jpradley.jpr.com...
>
>> Fabio Giannotti propounded (on Sun, Feb 04, 2001 at 05:01:35PM
>> -0600): | John DuBois <jo...@sco.COM> wrote in message
>
>news:95hk7b$r87$1...@hobbes.sco.com...
>
>> | > In article <inGe6.1350$9r5.2...@news1.primary.net>, Fabio
>> Giannotti
>
><fab...@venmar.com> wrote:
>
>> | > +In SCO 5.0.x is there any way to allow a user to ftp into
>> | > +your box, and have all functionality EXCEPT retreiving
>> | > +files?
>> | > Are you talking about anonymous ftp?
>> | > +(Changing permissions on the given files to remove read
>> | > access is not an option.)
>> | > Why is that? The usual method (for anonymous ftp) is to use
>> | > the 'upload' keyword to set the permissions on uploaded files
>> | > such that the user can't read them back, e.g.:
>> | > upload /u/ftp /incoming yes ftp group 0044 nodirs
>> | No, I am not talking about anonymous FTP. We don't use anonymous
>> | FTP for a variety of reasons. I want a user who is a valid user on
>> | my system to be able to upload files to a specific directory, but
>> | not download anything already in that directory. I can not change
>> | permissions on the existing files because they need to have global
>> | read access for other reasons.
>> John already told you. You set that directory so that no one can read
>> it, anyone can upload to it, and every file uploaded immeidately gets
>> its permissions/ownership changed
>I'm sorry if I am not being clear. Changes file permissions on the
>directory or the file IS NOT an option. I was wondering if there
>were any way to disable the "get" feature in ftp, I guess not.
Why don't you tell us exactly what you are trying to accomplish
and nothing more. What is clouding the issue for me is that you
said you want any regular user to be able to upload to that
directory but not download from it. Yet you also said you want to
have global read access. That would mean to me that any user
should be able to copy the file to their own directory and download
from there no matter what you prevent at the time of upload.
A file readable by a user is readable by a user whether it is a
local keyboard, telnet, http, or ftp.
What's to prevent a user from accessing that file by any other
method than ftp if they have read access. There is http, scp,
simple 'cat', and so on.
I think JP's answer is what I was looking for, I just hoped to be able to do
it with what was provided by default with SCO 5...
Thanks,
Fabio
Thanks, that is the info I was looking for. I thought the ftpd provided
with SCO 5.0.5 and 5.0.6 was wu-ftpd. Is it not?
Thanks,
Fabio
There is no doubt in my mind that the current ftpd in OSR 5 is derived
from wu-ftpd. But it surely is not the latest release, and it does seem
to have been a bit simplified,
--
JP
>> Why don't you tell us exactly what you are trying to accomplish
>> and nothing more. What is clouding the issue for me is that you
>> said you want any regular user to be able to upload to that
>> directory but not download from it. Yet you also said you want to
>> have global read access. That would mean to me that any user
>> should be able to copy the file to their own directory and download
>> from there no matter what you prevent at the time of upload.
>> A file readable by a user is readable by a user whether it is a
>> local keyboard, telnet, http, or ftp.
>> What's to prevent a user from accessing that file by any other
>> method than ftp if they have read access. There is http, scp,
>> simple 'cat', and so on.
>Actually, I said I wanted *a* not *any* regular user to be able to
>ftp in. The user is set up as an ftp only user whose root directory
>is changed to the directory in question. They do not have any other
>access to the system, and thus can not "read" the files in any
>other way...
Sorry. I did not intrepret it that way.
>I think JP's answer is what I was looking for, I just hoped to be
>able to do it with what was provided by default with SCO 5...
Here is one that should also work. Since it is *a* user, their
home directory will be the directory to which they will upload the
files.
Make a separate group for that user and make it their group. Change
the directory permission so the group he is in has only write
permissions to that directory. Make the others - readable
drwxr--r-x for the directory. Since permissions are evaluated left
to right, and the person uploading is in the group, the read will
fail at that point, and it doesn't make any difference at all
even it the 'others' field were rwx.
You can use this technique to exclude users from a set of files
while giving everyone else full access. Haven't tried this on ftp
however.