Comments (13)
if we make it configurable, what's the best way to check which filesystem the tomb is formatted?
I mean, without mounting it?
this is needed for instance in case one calls resize on a non-EXT tomb, the command should refuse to function.
from tomb.
On 17/01/2012 18:09, Jaromil wrote:
if we make it configurable, what's the best way to check which filesystem the tomb is formatted?
I mean, without mounting it?
this is needed for instance in case one calls resize on a non-EXT tomb, the command should refuse to function.Well, if we want to do some quick job, we can use sfdisk.
If we wanto to do some good (but hard) job, we must use hexdump (or xdd)
to check the offset byte partition and match with a predefined set of
'tomb supported filesystem'.
This will go togheter to #45 that I
want to code (I'll start it this weekend).
If we choose one of these approaches, I can code this into #45 and then
adding this feature to 'resize' command.
Anathema
+--------------------------------------------------------------------+
|GPG/PGP KeyID: 0F26965C available on http://pgpkeys.mit.edu:11371/ |
|Fingerprint: F808 18A2 2E7D 6E7A 7A18 4062 0AA3 7BF2 0F26 965C |
| |
|http://www.msack.org |
|https://tboxes.tracciabi.li/anathema
+--------------------------------------------------------------------+
from tomb.
Bumping this issue since I want to use ZFS now on some tombs. It features history and compression.
So I'll take it from here and hack something together soon. I think of a -t option (like with mount) on lock()
Tomb also needs to save information on how it was formatted, or even better detect (with sfdisk?)
Will try ASAP. So far I can see useful options for EXT2/3/4 and ZFS, not sure what else.
FAT is not looking like a sane option since Tomb works anyway only on Linux...
from tomb.
I find -t
perfectly fine for specifying filesystem.
I don't think there's any need for saving this informations; linux
should autodetect how to mount filesystems.
I think FAT is great for most tombs, but that's another story :)
from tomb.
ZFS works in a very different way than other Linux filesystems, it needs to have ad-hoc code for its usage.
Why do you think FAT is great? can you sketch a situation where it would be useful?
If you want Windows and Apple computers to access the contents of a Tomb, what about sharing it via Samba?
from tomb.
On a computer, my UID is 1001. On another one, my UID is 1002.
Sharing a tomb between these two computers is a pain.
FAT would solve these problems.
from tomb.
Don't use FAT to solve such a problem. FAT will never make it in Tomb for such a reason, it is a complex way to solve a simple problem and implies huge drawbacks.
Besides, look at line 1511:
chown ${_uid}:${_gid} ${tombmount}
chmod 0750 ${tombmount}
why that is not working for you?
any other reason you like to put forward to advocate use of FAT?
from tomb.
any other reason you like to put forward to advocate use of FAT?
nope. That is the only one. I'll doublecheck the chown you pointed me
from tomb.
why that is not working for you?
Probably because it does not change the ownership of the files inside the Tomb.
Indeed, that's an interesting issue. I have it also. We could take advantage of the hooks to chown -R
the contents to the UID that mounted the tomb, but I see two issues there: 1) all files might not share the same UID and GID inside the Tomb for specific reasons, and 2) the user mounting the Tomb might not have the right to perform that operation (even if sudo
is available).
If the user gets to the point she needs to own the files, we can safely assume she is the right owner of the Tomb, so we could simply add chown -R ${_uid} ${tombmount}
(leaving the GID unchanged for files inside the tomb).
from tomb.
ACK, true there is no -R in that chown I've pointed.
Hellekin analysis here is fairly complete.
about 1) yes, "specific reasons" come in mind, however I can't think of many real life cases where they are needed and in such cases such specific usage can be fixes with post-hooks. Enough to ignore the 1) issue I'd say.
about 2) if its tomb executing the chown... should be fine.
so the suggested solution of a chown -R of the ${_uid} alone is fine for me, but it should be specified in the documentation and bypassed by the -n option, together with the hooks.
from tomb.
I agree that the cases for multiple owner are not much; I can not say the same thing for the mode; therefore, I propose
chown -R ${_uid}:${_gid} ${tombmount}
chmod 0750 ${tombmount}
So that the chmod is not recursive
from tomb.
Hmmm no. The GID is often more significant than the uid, especially for giving read-only access to some applications, or other users. Please do not touch the GID :)
from tomb.
I just want to toss one more fs onto the list. XFS if possible. Thanks for taking it into consideration.
from tomb.
Related Issues (20)
- tomb complains about zramswap HOT 5
- btrfs on small tombs HOT 2
- Tomb 2.9.0 as root with smartcard [Bug? + Workaround] HOT 3
- Tomb `online / offline` command for LAN sharing via samba
- Question: How secure is storing the secret.tomb file along with they key file relying only on password?
- Support .wav file in bury/exhume mode which `steghide` already support HOT 3
- age support for key encryption HOT 1
- mountpoint `/run/media/$USER` always with root ownership HOT 10
- `ctrl+c` not working to cancel `sudo` prompt
- Duplicate password prompt when `udiskie` was installed. HOT 1
- tomb index / search and mlocate HOT 2
- portable tomb on osx with fuse-t HOT 1
- How to properly avoid dozens of password prompt when using `--sudo doas`? HOT 10
- What is the purpose of `tomb-kdb-hexencode`? HOT 7
- Privilege Escalation HOT 9
- Could you add Portuguese (Brazilian) to Weblate for localization? HOT 1
- cloakify support: update to python3 HOT 4
- Translations help - perl or shell script? HOT 2
- tomb --version and tomb-kdb-pbkdf2 HOT 7
- I got error message "is_valid_tomb:local:57: not valid in this context: " when I ran the command "tomb lock -k secrets.tomb.key secrets.tomb" for testing. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tomb.