On Tue, Oct 23, 2001 at 10:57:08AM +0200, guy keren wrote: > On Tue, 23 Oct 2001, Adi Stav wrote: > > > > in any event, you just gave me another idea for what could be achived with > > > 'syscall parameter rewriting' - a good thing for syscalltrack ;) (once it > > > supports syscall paramerter rewriting). > > > > What for? This is policy in the kernel, overwriting explicit user > > choices in order to achieve ends that can be reached through other > > means. If a sysadmin has SGID directories, all they need to do is to > > to set the default umask to 002. > > because i don't WANT to set umask to '002'. i always set it to '077', in > fact, on multi-user environments. and then, there are certain directories > in which i want to be able to collaborate with several other people, and i > have to manually make sure files get proper permissions. and in _those_ > directories, _i_ (the paranoid 077 umasker) WANT files to be accessible to > the group _by default_. and since there's no 'umask-per-directory' yet, > then i'm stuck. and too many times i had problems because of these issues.
If each user has their own group, you can safely set your umask to 007. There is no security advantage to 077 if you are the only user in your group. No one will be able to access your files unless you create them in a directory that belongs to a different group and that has the SGID bit set. This is how it is done in Debian, precisely for this reason. > and there aer other directories in which i want the group to have 'read' > access, but not 'write' access (e.g. ~/public_html - want the web server's > user to be able to read the file but not write into it). I'm sorry, apparently I misunderstood the system. For some reason I was under the impression that files are created with the permission of their parent directories, and that umask is only a "final veto". Now I checked this: the parent directory's permission is irrelevant. Perhaps all we need, then, is file creation semantics like what I though they were. Maybe this can be signified using some unused bit in the umask? Then you'd be able to set your umask 007, your $HOME 771, and your $HOME/public_html 775. Alternatively (and this might require no new OS features), just define some group that everybody is a member of (or at least the web server), chgrp public_html to it and chmod it 2770. ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
