tricky CHMOD

this is a bit of a tricky situation, so lemme explain first:

compaq desktop, openBSD 3.5
samba (newest version as of 2 weeks ago)
vsftpd (nothing less, again, latest version)

samba configured for 2 users (maybe more, all have equal permissions)
/share mounted on a 40gb hd
/share/video mounted on a 120gb hd
/share/audio '' '' '' 80gb hd
/share/software on the 40gb, regular folder
/share/incoming ''

one laptop, just for mobile use, needs same permissions as desktop
one desktop, runs shareazza (it's windows, it will get trashed sooner or later, but my files are all on BSD so they will last forever)....writes the temp (while downloading) files to local hd, final storage is on /share. files are then moved around into dirs as see fit

heres my goal:
right now it all works, i manually have to chmod several things and chown several things for different situations
i also run a ftp as all of this
ftp is vsftpd, config i dont think is that important, but key parts are it has no chmod permission (dont need it, use ssh for it) and no other permissions...just r+w...user is ftp
key system accounts:
root (duh), fcisler, ftp, share, public
fcisler = me (would like to have full permission of /share)
ftp = ftp account (system)
share = user and group of all /share...also what samba aliases too
public = ftp user account (public user)
all are system accounts
when i put a file in via samba i get permissions of 764...../share/incoming is owned by root, group is share, 777,  the user "public" puts files  into there as public, group is share, 755

everything else is owned by share, and group share, 755
it all works, although is a bit of pain for matinence
i know i can probally chown the ftp (vsftpd.conf) incoming and maybe samba (smb.conf), BUT what is the best way for it all to be managed through a windows computer?

-I want the /share/incoming to be writeable and resumeable by "public" and every other user, but not readable by public. Every other dir /share/* (minus incoming) should be full access by fcisler (ssh and samba) and share (just samba).
-All files that come in by samba should allready be set to same permission as /share/* (- incoming)
-General security for all is running ftp, so public should be able to read /share/* but not modify, and not read /share/incoming, but upload and resume

This one is tricky, it deals with alot of permission and probally sticky bits (i still dont know what they do specifically), so heres the breakdown
-provide me permissions, user and groups for /share/*
-permissions, user, groups  for /share/incoming/
-provide for both folder and files
-provide what ftp user should write to /share/incoming as

And i will give you the points, if you can explain it really well, AND/OR provide parts of smb.conf and vsftpd.conf where i should look, i can increase the points.....

Thanks in advance for help, if you have any questions...ask

Who is Participating?
de2ZotjesConnect With a Mentor Commented:
I had a look at your question. You want 2 levels of access for directories: fcisler+share and public. F+S have basically full rights and P has read rights. 2 levels is no problem, you can set owner and group rights, that is 2 levels. The problem arises from the fact that you want 2 users to have the more extended rights. You don't want to make the files P owned :-)

So you are left with no other choice than accepting that the rights for F+S will come from group membership and the rights for P must be the rights for other. What you need to do is create a group of which both F and S are a member. This is the group that you set on all files and directories in the /share subtree:

chgrp -R <thegroup> /share

You want the owner and group to have rw and the other to have r on files:

find /share -type f --exec chmod ug+rw,o-w+r \{} \;

On directories your want x for everybody, and the same rw and r as for files. In addition you want new files created in directories to the owned by the we previously set (the chgrp-command), so you set the set-group-bit (often wrongly referred to as the sticky-bit):

find /share -type d --exec chmod a+x,u+rw,g+rws,o-w+r

After this set of actions you have the permissions you want for existing files. New files will be created with the proper owner ships, but you will have to tell the programs writing to the disks what permission bits to set. For samba this means that you set:

force create mode = 0664
force directory mode = 2775

The settings for vsftp I don't know now, I am not at a site running that server, and I am to lazy to go googleing :)

There is one problem left: the incoming directory and  it's children. The rights for other are not correct, let's  fix that now:
find /share/incoming -type d -exec chmod o-r+w \{} \;
find /share/incoming -type f -exec chmod o-r \{} \;

The very last problem: new files in the incoming directory are readable to public would have to be solved from the vsftp configuration, and as I said I am to lazy to go on readabout.

There is an issue with this kind of setup and samba access. A lot of the time you will not be able to delete files since only the owner of a file can delete it. This is different from the behavior most windows users expect. You will therefore frequently see the use of a dummy user on a samba share. You make all files and directories owned by the dummy user and you tell samba to always access the share as the dummy user... This will emulate windows behavior.
Changing ownership:

chown -R <dummy> /share

Configuring samba:

force user = "<dummy>"

This is roughly the way I would set it up (and have set it up on several sites).
when parent directory is g+s or u+s it inherits respective uid/gid on file creation .
fcislerAuthor Commented:

but it dosen't, i did a chmod -R 1755 before i did any of the scenarios above, and it's still the same situation....sticky bit is set, and it dosent make a difference
as far as if i am root or fcisler and do nano /share/video/test.txt then yes, the permission will be set, but i will do that 1/1000th of the time, rest of the time it is samba or ftp
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

you just set sticky bit on directory, so it behaves more like /tmp
set g+s for desired effects
man chmod ; man sticky for more info
fcislerAuthor Commented:

not to sound obnoxious, but don't you think i have read the man? i also have told you that i set sticky bit on the directory and all files (chmod -R 1755 * has the effect) and it still does not inheret permissions for FTP or for samba.....i am not saying it isnt smb.conf or vsftpd.conf, but the sticky bit means nothing in this case....

instead of telling me set the sticky bit, maybe you could give more insight into what i would want the rest of the permissions to be....
i am not asking "hold my hand and show me how to do it", i teach myself what i need to learn
and as i said, it is working....i am just curious as to what other ways i can acomplish this.....
# smb.conf:
  path = /path/to/share
  create mode = 755
;  or 644 if not executable
  directory mask = 2775
  force group = your-prefered-group-here

the initial directory still have g+s set, so restart samba and it should do the trick.
For ftp it depends on your ftpd, usually there is a umask configuration setting

FYI. Setting the sticky bit on a directory (not applicable for files), means that only the owner of the file can delete it if you don't have write permission on the file.

fcislerAuthor Commented:

Thank you, very good suggestions....couple questions:

1) Groups "share" has users "fcisler" and "share" in it, so this will be my group....should share or fcisler have ownership? Share, right?
2) new folders should be chmod'd to 2775, and new dir's to 0664... or did you mean 1775 for dirs (why would i want setgid?) correct?
3) as a quick and dirty fix for the incoming dir, could i deny execute, so they cannot get a dir listing? that way they can upload a file (and resume) but not list any files? would that work?

Thanks for the help, gonna test it out now

 1) ownership is basically up to you, I would try to set it to the user that is most active on the filesystem.
 2) folders ( = directories ) should be 2775, files 0664. The role of the setgid-bit is different for a directory than it is for a file, you want setgid because when set on a directory setgid will cause all new files created in that directory to have the same group as the parent directory.
 3) Again the role of the bits is slightly different for dorectories than it is for files. The execute bit does not control reading the directory, it controls the ability to "cd" to that directory. If you want the world to be able to write but not read, then set the bits to just that: chmod o-r+w /share/incoming. Leave the execute bit set.
1) "share" is a group, so it could not have ownership, If I understand your description corrctly
2) new folders should be chmod'd to 2775, and new dir's to 0664 ...
    what is a folder for you?
   Unix only have dirs, and for your purpose they should hav 27xx (where xx to be replaced for your needs)
    About 17xx see previous comment: it enforces that anything in that dir can only be deleted by the owner
3) you're correct that a missing x-bit denies the listing, but if Samba can write then anyway needs to be tested, sorry I don't know for shure
fcislerAuthor Commented:

Thank you again. Part of this looks a bit wacky to me.
If i do a ls -l in /share i get the following
drwxrwsr-t   31 share share 1636 Oce 17 22:07 audio
drwxrwsrwx etc etc incoming

d means dir
rwx = read + write + execute
rws = read + write + execute (with sticky bit set?)
r-t = read + sticky bit (also executable?)
am i correct? is this what i want?
ls -l /share/audio/onyx
-rwxrwxr-t share share etc filename.mp3
is this correct again?
I'm trying to get these permissions set, test it out with samba, then i wanna work on vsftpd, because there is a chown_uploade flag, but no chmod uploads flag...i'm going to play around with owner and group of incoming and see what different effects it has on uploads via ftp and control via samba.....

thanks again for the help
ahoffmannConnect With a Mentor Commented:
> rws = read + write + execute (with sticky bit set?)
yes ("sticky" means gid or uid-S-bit set)

> r-t = read + sticky bit (also executable?)
yes, but keep in mind that the "sticky" here is on a file, where it has a different meaning than on directories, do you want to have stycky bits on files? I don't think so.
fcislerAuthor Commented:
just been messing around with it, couple thing
changed find /share -type f --exec chmod ug+rw,o-w+r \{} \; to
find /share -type f -exec chmod ug=rw,o=r \{} \;
and find /share -type d --exec chmod a+x,u+rw,g+rws,o-w+r to
find /share -type d -exec chmod u=rwx,g=rwxs,o=r
and ran it to replace all my old permissions, so now each dir looks like
drwxrwsr-t which is what i believe i want
each file now has
i believe i want all of that, but not sure what T is....does that mean it's inhereting sticky? is this a good security setting for all the files/folders?

sticky bit is needed for /tmp, /var/tmp /usr/tmp, and nowhere else, get it out of your head please.

historically it sticks binary programs into memory, so they run faster, but no modern system supports this, since normal coloured and unified buffer cache handles main purpose of sticky bit just fine.
fcislerAuthor Commented:

then why are ahoffmann and  de2Zotjes suggesting i use it on the dirs? man sticky gives "...indicate special treatment for directories" says nothing of sticking binary programs into memory, maybe you can elaborate on why i dont need it?
There is some confusion about the names of various bits that can be set.

There are 3 bits that we are talking about here: setuid, setgid, sticky.

So in essence gheist is right in saying that you do not need (or want) to set the sticky bit. However a lot of times the setuid and setgid bits are referred to as "sticky bits" when people are talking about them in relation to directories. This arises from the function that these bits have when set on a directory: they make the owner or group "sticky". It is an unfortunate clash of names that occurs...
and ffs supports few extra bits via chflags and setfacl commands, especially uchg ,which will ensure that gid of file is not changed by nasty programs like samba or ftp servers
and please do not start asking just what is the text and how to type it or so.
sticky, setuid etc.
and another often used term is s-bit
As de2Zotjes explained, you need to know which s-bit you mean when saying "sticky". Think I used it correct: sticky is o+s

About o+s on directories: in most cases it behaves as described: only owner of a file can modify/delete it in a "sticky directory".
But AFAIK this depends on the filesystem, currently I don't know of any which behaves different (old ufs on SunOS does).

fcisler, did you check your smb.conf settings, in particular "create mode" and "directory mask"
Ahoffman: o+s is meaningless, it iseither o+t which is the sticky bit, or u+s which is the setuid bit
fcislerAuthor Commented:
de2Zotjes and ahoffmann, thank have both been very helpfull....i'm going to raise points to 500 and split between you.... sound like you have a serious anger problem or something.....i quote from my previous post
"man sticky gives "...indicate"
do you not think i know how to read the man pages?
was i not asking the question for help, and to understand the difference between the three "sticky" bits? i think i have a good enough general understanding now to where i can sort out the little quirks myself.....but you seem to just try and put me down and act like i am an's not appreciated nor warranted....thanks to the others who helped....
> o+s
damn, have to be o+t for shure, sorry
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.