proftpd.umask

[Какие-то урывки из FAQ... Потом разбираться буду...] I am having some trouble. I looked through all of the FAQs, but couldn't find anything. I looked in the different configurations, and it wasn't much help. I was hoping someone could help me with this problem, if not through umask then some other method. Every time I create a directory through FTP, it is automatically chmodded to 022. Now, I found in proftpd.conf it said: Umark 022 So I got smart and changed it to 755, as that is what I want directories to be at when they are created. But it still is at 022. Does anyone know how to solve this? Is there another way? Thanks.

I set the umask back to 022 and now when I upload files or make directories, the permissions are set tono one allowed to read/write/execute. Any other way around this? I do have umask 022 in a global block too.

Vincent Paglione wrote: > > Hello, > I set the umask back to 022 and now when I upload files or make > directories, the permissions are set tono one allowed to > read/write/execute. Any other way around this? I do have umask 022 in a > global block too. So your effective umask is 0777 now ? If your configuration does contain only umask 022 or less, your server is apparently started with this setting. Check the environment from which you start proftpd.

Vincent Paglione wrote: > > > So your effective umask is 0777 now ? If your configuration does contain > > only umask 022 or less, your server is apparently started with this > > setting. Check the environment from which you start proftpd. > > -job > > Can you please explain this a little more? Thank you. If you play around with the "umask" command in the shell you will get a good idea what it is doing. For instance: rm a; umask 0 ; touch a ; ls -l a rm a; umask 0777; touch a ; ls -l a rm a; umask 022 ; touch a ; ls -l a The umask is a property of a process and is inherited by its children, so if you start proftpd from a shell script that sets its umask it will start proftpd with that umask. Wait - hold that, i just looked in the source, and i think proftpd resets its umask to 022 (or to the value in the config file). So forget what i said about checking the environment. It must be something in that file. -job

Well from the way i undersood it, Umask 022 sets all directories to be 755 and all files 644, i think..... I think your problem came when it said umark instead of umask in the config file. Also by setting the umask to 755, your chmod becomes 022. To get your chmod from umask you subtract the umask # (In this case it's 022) from 777. So: 777 - 022 = 755 Sorry if I couldn't state this more clearly but I am not good at explaining things and I am still a Linux/Unix newbie.

execute should NOT be set as the default on files (on directories it is), so you can't do it. use chmod to get them executable if they need to be executable.

I'm running ProFTPD 1.2.0pre10 for a few weeks now on a server mainly use= d for customers websites. Someone made me notice this problem today : All files uploaded have 644 permissions whereas directories do have 755... Since I've put a "Umask 022" directive in my main server config part, I don't understand why I don't get 755 permission on created files... I used to have BeroFTPD working fine (for a few years), I've also tried t= o search for help or clues in the faq or in the ML archives but without success :( Here's what my config file looks like : [Begin proftpd.conf ...] ServerAdmin ftp@asi.fr ServerIdent on "FTP Server Ready - Webpro asi.fr" ServerType inetd DefaultServer on SystemLog /var/log/proftpd LogFormat default "%h %l %u %t \"%r\" %s %b" LogFormat detail "%{%a %b %d %H:%M:%S %Y}t %h %b %f (\"%r\= ")" LogFormat fichiers "%{%a %b %d %H:%M:%S %Y}t <%h> %b bytes, = %f" TimeoutStalled 300 RootLogin on # Umask 022 is a good standard umask to prevent new dirs and files # from being group and world writable. Umask 022 User nobody Group nogroup IdentLookups off DefaultRoot ~ !root DefaultTransferMode binary # Normally, we want files to be overwriteable. <Directory /*> AllowOverwrite on Umask 022 </Directory> [...End] (the <VirtualHost>s have been removed) The Umask in the <Directory /*> has been added just to test... but it doesn't work better. Any comments, ideas are very welcome since all my users have to use the chmod command for now! Thanks :)

This is usually treated in introductory Unix courses, it has been the custom since 1973 (+/-) to set the default file permissions on files to 666 and directories to 777, and subtract umask from that. Are your users uploading programs ? -job

Yes, the problem in having 644 (666 minus the 022 Umask according to what you say), is that all uploaded files (including cgi scripts) aren't executable... Is there a way to have them all in 755 mode again? Or maybe with a <Directory ...> only for ~/web/cgi-bin/ ? Thanks for any help, I'm desperate to have those cgis +x right after uplo= ad :)

I just looked in the source, but not long enough to find a spot where the default permissions could be set to 777. Perhaps in fs.c:std_creat - which would probably mess up the umask directive. The proper thing would be something like a new directive FileMode, with same context as Umask, so it could be used in .ftpaccess files. At my current programming speed it would take me 3 years if i would not get distracted. You could shellscript it in 6 minutes of course, from the log.

I had a big problem with the second parameter of the "Umask" directive. (Better said I couldn't get it worked.) I think there is a bug in the dir_check(_full) function in the file dirtree.c.

The functions check only the existing directories when searching for the right umask while when MKD (or XMKD) command is issued, the directory (usually :-) doesn't exist. After adding the test whether actual command is (X)MKD is umask set up properly.

I have been checking the ProFTPD archives, and am currently using ProFTPD 1.2.0pre10 to provide FTP functionality to the web server I administer. My problem is that the permissions on my server are screwed = up (mask 0755 for all files and directories). I have been able to set the directory permissions correctly using the Umask directive, but not the file directives (which need to be the directory equivalent of 0755, if that makes sense). This is actually two questions - one, is there still a problem with the Umask directive, and two, how do you calculate octal permissions? I understand that you need to generate the octal code from a list (which is how I came up with 0755) and subtract it from 777 to get the correct umask for directories and 666 for files, but doing 666-755 results in a negative, non-octal number - how would I convert the directory octal mask that I already have to the file octal mask that I need? Thanks in advance for any help you can give on either = of these questions.

The UNIX permissions are not octal. The permissions are a combination of the following values: 1=eXecute, 2=Write, 4=Read. To get the mask just subtract each value from 7: 777 755 022 <- This is the umask that you want.

Hm. Well, I've recompiled ProFTPD, this time with the Y2K patch that was just posted to the list, along with linuxprivs (thought I had it compiled in but I guess not..?). The server still completely ignores the second paramater on Umask.. however, if I set the Umask to 0027, the execute bits are automagically stripped from regular files (they stay on new directories though). By exploiting this behavior I've been able to set the default file permissions on upload files to the way I originally wanted them to be, and since users in the group public (A) have no real shell, (B) are denied use of the SITE CHMOD command, and (C) can't even talk to the machine on ports other than 20, 21, and 80, they'll stay that way. Woo.

However, I am getting one strange problem. I've got this in my config: <Directory ~> <Limit ALL> Order deny,allow DenyGroup public AllowAll </Limit> <Limit TYPE STRU MODE STOU ABOR STAT ALLO APPE REST READ LIST NLST \ STOR RETR DELE MKD RMD CWD RNFR RNTO XMKD XRMD XPWD XCUP \ NOOP PWD CDUP> Order allow,deny AllowAll </Limit> </Directory>

That long line I split a couple times isn't actually like that in my config.. it's all one line.

Strangely enough, this results in users who are not members of group public to be denied access to NLST while in their home directories. They can NLST anywhere else on the filesystem, but once they get within their home directory (and within the scope of those limits, I presume), they're denied NLST (but strangely enough, any of the other commands listed in the block with NLST work fine). I am completely confused by this. Anybody have any idea how this ends up happening? My goal is to ensure that as far as group public goes, anything not explicitly permitted is forbidden. In particular, we don't want users in group public changing permissions on their files, although after reading the RFC, there's a large amount of other stuff that I'm cutting them off from, too. Any user in any other group besides public should have access to the full set of ftp commands.

On Mon, Mar 06, 2000 at 09:08:57AM -0500, Matthew Eash wrote: > What is a umask that will create 775? 002 However it will only be the case for entries which would have the execute bit set on them by default - directories in otherwords. Files will have the mode of 664 with the above umask.

That's true (having forgot to account for that in my other comments :)

The directories need x set to allow 'searching'. You cannot execute a directory ;)

which, unless I'm having a fit of moronic stupidity (which could indeed be the case =) should set those permissions correctly. It half works - permissions on normal files are set right, but permissions on directories are set to the same thing as normal files. It seems that the second parameter to Umask isn't been recognized at all.. I've tried mucking about with it to see if there were any changes when the second parameter was changed, but no dice..

<Directory ~> Umask 0007 </Directory> Note I have two umask settings, one in the server context for files and one in the directory context for dirs. This is very strange that it works like this, but this is the only way I've found! I run 1.2pre9 and FreeBSD 3.3. I would be very happy if the 1.2pre10 with y2k and umask fixes released this month!