On Mar 31 20:41, Eliot Moss wrote: > On 3/31/2015 4:55 PM, Andrey Repin wrote: > > >> I am not sure this particular program (CrashPlan) works that way. > > > >That's not program property, but the user you run the program from. > > Perhaps, but it runs as a background service. I never explicitly said what > user it runs as, etc. > > Looking in Services, I see is logs on as "Local System account". Using > Process Explorer, it appears to run without SEBackup/Restore privileges. > Since the program has to request them itself as it runs, I don't see any > good way to fix this. > > >I think i've explained it earlir, but here's it again: > >In POSIX model, root have implicit permissions. > >In Windows model, there NO implicit permissions at all. Everything should be > >explicitly assigned. I.e. SeBackupRestore privilege. > >If you deny SYSTEM access to a file, OS will not be able to do anything about > >it. Been there, blocked changes to cmd.exe when I was experimenting with 4NT. > >(And cmd.exe was in fact renamed 4nt.exe.) None of the Windows autotools were > >able to get around it. > > Yes, I get that. Hence my desire to grant SYSTEM:rwx on everything. > > What we seem to have ended up with here, though, is that the > root privileges are explicit and are exposed in the ordinary permissions > visible > with, say, ls -l.
Huh? ls -l (that is, stat(2)) shows the permissions in the same way as they are computed on a POSIX system. The mask value is just faked from the existing permsissions, but other than that, it does what POSIX 1003.1e requires. > This is not natural from a POSIX point of view (I claim); > otherwise, we'd more or less show access of rwxrwxrwx on everything in POSIX. I don't grok that. POSIX shows the permissions exactly as they are, with the group permissions being the primary group perms or the mask value if there is a mask. On Cygwin the mask is faked, but it shows the combined permissions of all non-primary users and groups, so it's a good fake. So in both cases the group permissions show you where's a security problem. Granting SYSTEM access to the kitchen sink is a Windows thingy, and a bad one as well. Rather than just asking the developers to enable the SE_BACKUP_NAME/SE_RESTORE_NAME rights when needed, they now add full access for SYSTEM and Administrators by default every time. That's a bad hack and totally unnecessary, too. But Cygwin adds SE_BACKUP_NAME/SE_RESTORE_NAME rights to the processes by default, so in theory you don't need full SYSTEM access inside your Cygwin tree. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpy2I57Fgl8C.pgp
Description: PGP signature
