yes, correct - that is a valid objection! in my setup, there will be no local users on that server and the remote-users typically will use their own box... regards roland > Gesendet: Mittwoch, 29. Juli 2015 um 12:22 Uhr > Von: "Anton Altaparmakov" <anton@xxxxxxxxxx> > An: "devzero@xxxxxx" <devzero@xxxxxx> > Cc: "linux-fsdevel@xxxxxxxxxxxxxxx" <linux-fsdevel@xxxxxxxxxxxxxxx> > Betreff: Re: acl/directory security question > > Hi, > > This is not safe at all because imagine for example user A copying a file from/to the hidden directory like so: > > $ scp /your/hidden/dir/some/file somewhere/else > > And user B at same time doing: > > $ ps ax > > The ps ax output will show the scp command including the full paths above thus your secret directory was just revealed to user B even though only user A was meant to know about it... > > Best regards, > > Anton > > > On 20 Jul 2015, at 15:20, devzero@xxxxxx wrote: > > > > hi, > > > > please forgive if this is a little bit offtopic here or sounds dumb... > > > > i`d like to implement a file-sharing solution for an internal lan and > > consider sharing a directory via different protocols/daemons and place > > "secret" subdirs inside. > > > > let`s say, i chmod the parent directory to 711 (rwx--x--x), any non-root > > user get`s "permission denied" when trying to list the subdir`s contents. > > anyway, he will be able to access the contents of a secret subdir if > > that subdir is at leaast readable for him and he knows the subir`s name. > > (examples see below) > > > > can such a method of hiding subdirs and creating names which cannot be > > guessed considered to be a safe method, or is there some way to bypass > > this sort of protection ? (despite software/kernel bugs, brute-force or > > admin error like setting wrong acl) > > > > is there some "list the content`s of the first, second, third dir" or > > "list directory contents by inode"-syscall ? > > > > as nobody of the linux people i asked could answer this barely sufficient > > to me, i`d like to ask some people who really may know about... (as you`re > > into acl, vfs, syscalls and that stuff) > > > > thanks > > roland > > > > > > > > > > root@linux:/daten# ls -al > > total 100856 > > drwxr-xr-x 7 root root 4096 Jul 17 13:55 . > > drwxr-xr-x 23 root root 4096 Jul 30 2014 .. > > drwx------ 2 root root 4096 Feb 2 16:53 lost+found > > drwx--x--x 4 root root 4096 Jul 17 12:35 sharedir > > > > root@linux:/daten# ls -la sharedir/ > > total 20 > > drwx--x--x 4 root root 4096 Jul 17 12:35 . > > drwxr-xr-x 7 root root 4096 Jul 17 13:55 .. > > drwxrwxrwx 11 root root 4096 Jul 20 12:28 DUrXd3PgdGgj5th9 > > > > root@linux:/daten# su - roland > > > > roland@linux:~$ cd /daten/ > > roland@linux:/daten$ ls -la sharedir > > ls: cannot open directory sharedir: Permission denied > > > > roland@linux:/daten$ ls -la sharedir/* > > ls: cannot access sharedir/*: No such file or directory > > > > roland@linux:/daten/sharedir$ find . > > . > > find: `.': Permission denied > > > > roland@linux:/daten/sharedir$ tree --inodes -f -F > > . [error opening dir] > > > > 0 directories, 0 files > > > > > > roland@linux:/daten$ ls -la sharedir/DUrXd3PgdGgj5th9 > > total 48 > > drwxrwxrwx 11 root root 4096 Jul 20 12:28 . > > drwx--x--x 4 root root 4096 Jul 17 12:35 .. > > drwxr-xr-x 2 public public 4096 Jul 17 14:16 .DAV > > drwx------ 2 public public 4096 Jul 20 12:15 New Folder > > -rwxrwxrwx 1 public public 0 Jul 17 14:18 test > -- > Anton Altaparmakov <anton at tuxera.com> (replace at with @) > Lead in File System Development, Tuxera Inc., http://www.tuxera.com/ > Linux NTFS maintainer > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
